1. 30 Aug, 2022 10 commits
    • Pawel Laszczak's avatar
      usb: cdns3: fix incorrect handling TRB_SMM flag for ISOC transfer · d5dcc336
      Pawel Laszczak authored
      The TRB_SMM flag indicates that DMA has completed the TD service with
      this TRB. Usually it’s a last TRB in TD. In case of ISOC transfer for
      bInterval > 1 each ISOC transfer contains more than one TD associated
      with usb request (one TD per ITP). In such case the TRB_SMM flag will
      be set in every TD and driver will recognize the end of transfer after
      processing the first TD with TRB_SMM. In result driver stops updating
      request->actual and returns incorrect actual length.
      To fix this issue driver additionally must check TRB_CHAIN which is not
      used for isochronous transfers.
      
      Fixes: 249f0a25 ("usb: cdns3: gadget: handle sg list use case at completion correctly")
      cc: <stable@vger.kernel.org>
      Acked-by: default avatarPeter Chen <peter.chen@kernel.org>
      Signed-off-by: default avatarPawel Laszczak <pawell@cadence.com>
      Link: https://lore.kernel.org/r/20220825062207.5824-1-pawell@cadence.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5dcc336
    • Krishna Kurapati's avatar
      usb: gadget: mass_storage: Fix cdrom data transfers on MAC-OS · 9d4dc16e
      Krishna Kurapati authored
      During cdrom emulation, the response to read_toc command must contain
      the cdrom address as the number of sectors (2048 byte sized blocks)
      represented either as an absolute value (when MSF bit is '0') or in
      terms of PMin/PSec/PFrame (when MSF bit is set to '1'). Incase of
      cdrom, the fsg_lun_open call sets the sector size to 2048 bytes.
      
      When MAC OS sends a read_toc request with MSF set to '1', the
      store_cdrom_address assumes that the address being provided is the
      LUN size represented in 512 byte sized blocks instead of 2048. It
      tries to modify the address further to convert it to 2048 byte sized
      blocks and store it in MSF format. This results in data transfer
      failures as the cdrom address being provided in the read_toc response
      is incorrect.
      
      Fixes: 3f565a36 ("usb: gadget: storage: adapt logic block size to bound block devices")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarKrishna Kurapati <quic_kriskura@quicinc.com>
      Link: https://lore.kernel.org/r/1661570110-19127-1-git-send-email-quic_kriskura@quicinc.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d4dc16e
    • Alan Stern's avatar
      media: mceusb: Use new usb_control_msg_*() routines · 608e58a0
      Alan Stern authored
      Automatic kernel fuzzing led to a WARN about invalid pipe direction in
      the mceusb driver:
      
      ------------[ cut here ]------------
      usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40
      WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410
      usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
      Modules linked in:
      CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c65 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.13.0-1ubuntu1.1 04/01/2014
      Workqueue: usb_hub_wq hub_event
      RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410
      Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8
      44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b
      e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41
      RSP: 0018:ffffc900032becf0 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000
      RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90
      RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000
      R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000
      R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500
      FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0
      Call Trace:
      <TASK>
      usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58
      usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
      usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153
      mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]
      mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807
      
      The reason for the warning is clear enough; the driver sends an
      unusual read request on endpoint 0 but does not set the USB_DIR_IN bit
      in the bRequestType field.
      
      More importantly, the whole situation can be avoided and the driver
      simplified by converting it over to the relatively new
      usb_control_msg_recv() and usb_control_msg_send() routines.  That's
      what this fix does.
      
      Link: https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA@mail.gmail.com/
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: default avatarRondreis <linhaoguo86@gmail.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/YwkfnBFCSEVC6XZu@rowland.harvard.eduSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      608e58a0
    • Alan Stern's avatar
      USB: core: Prevent nested device-reset calls · 9c6d7788
      Alan Stern authored
      Automatic kernel fuzzing revealed a recursive locking violation in
      usb-storage:
      
      ============================================
      WARNING: possible recursive locking detected
      5.18.0 #3 Not tainted
      --------------------------------------------
      kworker/1:3/1205 is trying to acquire lock:
      ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
      usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
      
      but task is already holding lock:
      ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:
      usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
      
      ...
      
      stack backtrace:
      CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.13.0-1ubuntu1.1 04/01/2014
      Workqueue: usb_hub_wq hub_event
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
      print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]
      check_deadlock kernel/locking/lockdep.c:3031 [inline]
      validate_chain kernel/locking/lockdep.c:3816 [inline]
      __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053
      lock_acquire kernel/locking/lockdep.c:5665 [inline]
      lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630
      __mutex_lock_common kernel/locking/mutex.c:603 [inline]
      __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747
      usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230
      usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109
      r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622
      usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458
      device_remove drivers/base/dd.c:545 [inline]
      device_remove+0x11f/0x170 drivers/base/dd.c:537
      __device_release_driver drivers/base/dd.c:1222 [inline]
      device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248
      usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627
      usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118
      usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114
      
      This turned out not to be an error in usb-storage but rather a nested
      device reset attempt.  That is, as the rtl8712 driver was being
      unbound from a composite device in preparation for an unrelated USB
      reset (that driver does not have pre_reset or post_reset callbacks),
      its ->remove routine called usb_reset_device() -- thus nesting one
      reset call within another.
      
      Performing a reset as part of disconnect processing is a questionable
      practice at best.  However, the bug report points out that the USB
      core does not have any protection against nested resets.  Adding a
      reset_in_progress flag and testing it will prevent such errors in the
      future.
      
      Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: default avatarRondreis <linhaoguo86@gmail.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.eduSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9c6d7788
    • Alan Stern's avatar
      USB: gadget: Fix obscure lockdep violation for udc_mutex · 1016fc0c
      Alan Stern authored
      A recent commit expanding the scope of the udc_lock mutex in the
      gadget core managed to cause an obscure and slightly bizarre lockdep
      violation.  In abbreviated form:
      
      ======================================================
      WARNING: possible circular locking dependency detected
      5.19.0-rc7+ #12510 Not tainted
      ------------------------------------------------------
      udevadm/312 is trying to acquire lock:
      ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0
      
      but task is already holding lock:
      ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (kn->active#4){++++}-{0:0}:
              lock_acquire+0x68/0x84
              __kernfs_remove+0x268/0x380
              kernfs_remove_by_name_ns+0x58/0xac
              sysfs_remove_file_ns+0x18/0x24
              device_del+0x15c/0x440
      
      -> #2 (device_links_lock){+.+.}-{3:3}:
              lock_acquire+0x68/0x84
              __mutex_lock+0x9c/0x430
              mutex_lock_nested+0x38/0x64
              device_link_remove+0x3c/0xa0
              _regulator_put.part.0+0x168/0x190
              regulator_put+0x3c/0x54
              devm_regulator_release+0x14/0x20
      
      -> #1 (regulator_list_mutex){+.+.}-{3:3}:
              lock_acquire+0x68/0x84
              __mutex_lock+0x9c/0x430
              mutex_lock_nested+0x38/0x64
              regulator_lock_dependent+0x54/0x284
              regulator_enable+0x34/0x80
              phy_power_on+0x24/0x130
              __dwc2_lowlevel_hw_enable+0x100/0x130
              dwc2_lowlevel_hw_enable+0x18/0x40
              dwc2_hsotg_udc_start+0x6c/0x2f0
              gadget_bind_driver+0x124/0x1f4
      
      -> #0 (udc_lock){+.+.}-{3:3}:
              __lock_acquire+0x1298/0x20cc
              lock_acquire.part.0+0xe0/0x230
              lock_acquire+0x68/0x84
              __mutex_lock+0x9c/0x430
              mutex_lock_nested+0x38/0x64
              usb_udc_uevent+0x54/0xe0
      
      Evidently this was caused by the scope of udc_mutex being too large.
      The mutex is only meant to protect udc->driver along with a few other
      things.  As far as I can tell, there's no reason for the mutex to be
      held while the gadget core calls a gadget driver's ->bind or ->unbind
      routine, or while a UDC is being started or stopped.  (This accounts
      for link #1 in the chain above, where the mutex is held while the
      dwc2_hsotg_udc is started as part of driver probing.)
      
      Gadget drivers' ->disconnect callbacks are problematic.  Even though
      usb_gadget_disconnect() will now acquire the udc_mutex, there's a
      window in usb_gadget_bind_driver() between the times when the mutex is
      released and the ->bind callback is invoked.  If a disconnect occurred
      during that window, we could call the driver's ->disconnect routine
      before its ->bind routine.  To prevent this from happening, it will be
      necessary to prevent a UDC from connecting while it has no gadget
      driver.  This should be done already but it doesn't seem to be;
      currently usb_gadget_connect() has no check for this.  Such a check
      will have to be added later.
      
      Some degree of mutual exclusion is required in soft_connect_store(),
      which can dereference udc->driver at arbitrary times since it is a
      sysfs callback.  The solution here is to acquire the gadget's device
      lock rather than the udc_mutex.  Since the driver core guarantees that
      the device lock is always held during driver binding and unbinding,
      this will make the accesses in soft_connect_store() mutually exclusive
      with any changes to udc->driver.
      
      Lastly, it turns out there is one place which should hold the
      udc_mutex but currently does not: The function_show() routine needs
      protection while it dereferences udc->driver.  The missing lock and
      unlock calls are added.
      
      Link: https://lore.kernel.org/all/b2ba4245-9917-e399-94c8-03a383e7070e@samsung.com/
      Fixes: 2191c008 ("USB: gadget: Fix use-after-free Read in usb_udc_uevent()")
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: stable@vger.kernel.org
      Reported-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Link: https://lore.kernel.org/r/YwkfhdxA/I2nOcK7@rowland.harvard.eduSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1016fc0c
    • Heiner Kallweit's avatar
      usb: dwc2: fix wrong order of phy_power_on and phy_init · f9b995b4
      Heiner Kallweit authored
      Since 1599069a ("phy: core: Warn when phy_power_on is called before
      phy_init") the driver complains. In my case (Amlogic SoC) the warning
      is: phy phy-fe03e000.phy.2: phy_power_on was called before phy_init
      So change the order of the two calls. The same change has to be done
      to the order of phy_exit() and phy_power_off().
      
      Fixes: 09a75e85 ("usb: dwc2: refactor common low-level hw code to platform.c")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarMinas Harutyunyan <hminas@synopsys.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Link: https://lore.kernel.org/r/dfcc6b40-2274-4e86-e73c-5c5e6aa3e046@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9b995b4
    • Piyush Mehta's avatar
      usb: gadget: udc-xilinx: replace memcpy with memcpy_toio · 8cb339f1
      Piyush Mehta authored
      For ARM processor, unaligned access to device memory is not allowed.
      Method memcpy does not take care of alignment.
      
      USB detection failure with the unaligned address of memory access, with
      below kernel crash. To fix the unaligned address the kernel panic issue,
      replace memcpy with memcpy_toio method.
      
      Kernel crash:
      Unable to handle kernel paging request at virtual address ffff80000c05008a
      Mem abort info:
        ESR = 0x96000061
        EC = 0x25: DABT (current EL), IL = 32 bits
        SET = 0, FnV = 0
        EA = 0, S1PTW = 0
        FSC = 0x21: alignment fault
      Data abort info:
        ISV = 0, ISS = 0x00000061
        CM = 0, WnR = 1
      swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000
      [ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003,
      pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713
      Internal error: Oops: 96000061 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
      Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
      pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : __memcpy+0x30/0x260
      lr : __xudc_ep0_queue+0xf0/0x110
      sp : ffff800008003d00
      x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
      x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
      x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
      x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
      x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
      x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
      x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0
      x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112
      x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80
      x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088
      Call trace:
       __memcpy+0x30/0x260
       xudc_ep0_queue+0x3c/0x60
       usb_ep_queue+0x38/0x44
       composite_ep0_queue.constprop.0+0x2c/0xc0
       composite_setup+0x8d0/0x185c
       configfs_composite_setup+0x74/0xb0
       xudc_irq+0x570/0xa40
       __handle_irq_event_percpu+0x58/0x170
       handle_irq_event+0x60/0x120
       handle_fasteoi_irq+0xc0/0x220
       handle_domain_irq+0x60/0x90
       gic_handle_irq+0x74/0xa0
       call_on_irq_stack+0x2c/0x60
       do_interrupt_handler+0x54/0x60
       el1_interrupt+0x30/0x50
       el1h_64_irq_handler+0x18/0x24
       el1h_64_irq+0x78/0x7c
       arch_cpu_idle+0x18/0x2c
       do_idle+0xdc/0x15c
       cpu_startup_entry+0x28/0x60
       rest_init+0xc8/0xe0
       arch_call_rest_init+0x10/0x1c
       start_kernel+0x694/0x6d4
       __primary_switched+0xa4/0xac
      
      Fixes: 1f7c5166 ("usb: gadget: Add xilinx usb2 device support")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarPiyush Mehta <piyush.mehta@amd.com>
      Link: https://lore.kernel.org/r/20220824071253.1261096-1-piyush.mehta@amd.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cb339f1
    • Heikki Krogerus's avatar
      usb: typec: Remove retimers properly · b7cafb8b
      Heikki Krogerus authored
      Retimer device class is left dangling when the typec module
      is unloaded. Attempts to reload the module failed with warning:
      
              "sysfs: cannot create duplicate filename '/class/retimer'"
      
      Fixing the issue by unregistering the class properly.
      
      Fixes: ddaf8d96 ("usb: typec: Add support for retimers")
      Reviewed-by: default avatarPrashant Malani <pmalani@chromium.org>
      Signed-off-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Link: https://lore.kernel.org/r/20220825140411.10743-1-heikki.krogerus@linux.intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7cafb8b
    • Johan Hovold's avatar
      usb: dwc3: disable USB core PHY management · 6000b8d9
      Johan Hovold authored
      The dwc3 driver manages its PHYs itself so the USB core PHY management
      needs to be disabled.
      
      Use the struct xhci_plat_priv hack added by commits 46034a99 ("usb:
      host: xhci-plat: add platform data support") and f768e718 ("usb:
      host: xhci-plat: add priv quirk for skip PHY initialization") to
      propagate the setting for now.
      
      Fixes: 4e88d4c0 ("usb: add a flag to skip PHY initialization to struct usb_hcd")
      Fixes: 178a0bce ("usb: core: hcd: integrate the PHY wrapper into the HCD core")
      Tested-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Cc: stable <stable@kernel.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarJohan Hovold <johan+linaro@kernel.org>
      Link: https://lore.kernel.org/r/20220825131836.19769-1-johan+linaro@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6000b8d9
    • Jean-Francois Le Fillatre's avatar
      usb: add quirks for Lenovo OneLink+ Dock · 3d5f7094
      Jean-Francois Le Fillatre authored
      The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
      17ef:1018 upstream
      17ef:1019 downstream
      
      Those two controllers both have problems with some USB3.0 devices,
      particularly self-powered ones. Typical error messages include:
      
        Timeout while waiting for setup device command
        device not accepting address X, error -62
        unable to enumerate USB device
      
      By process of elimination the controllers themselves were identified as
      the cause of the problem. Through trial and error the issue was solved
      by using USB_QUIRK_RESET_RESUME for both chips.
      Signed-off-by: default avatarJean-Francois Le Fillatre <jflf_kernel@gmx.com>
      Cc: stable <stable@kernel.org>
      Link: https://lore.kernel.org/r/20220824191320.17883-1-jflf_kernel@gmx.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d5f7094
  2. 25 Aug, 2022 3 commits
  3. 23 Aug, 2022 2 commits
  4. 22 Aug, 2022 1 commit
  5. 19 Aug, 2022 5 commits
  6. 18 Aug, 2022 19 commits