1. 24 Sep, 2020 4 commits
    • Mauro Carvalho Chehab's avatar
      usb: dwc3: simple: add support for Hikey 970 · b68d9251
      Mauro Carvalho Chehab authored
      This binding driver is needed for Hikey 970 to work,
      as otherwise a Serror is produced:
      
          [    1.837458] SError Interrupt on CPU0, code 0xbf000002 -- SError
          [    1.837462] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205
          [    1.837463] Hardware name: HiKey970 (DT)
          [    1.837465] Workqueue: events deferred_probe_work_func
          [    1.837467] pstate: 20000005 (nzCv daif -PAN -UAO BTYPE=--)
          [    1.837468] pc : _raw_spin_unlock_irqrestore+0x18/0x50
          [    1.837469] lr : regmap_unlock_spinlock+0x14/0x20
          [    1.837470] sp : ffff8000124dba60
          [    1.837471] x29: ffff8000124dba60 x28: 0000000000000000
          [    1.837474] x27: ffff0001b7e854c8 x26: ffff80001204ea18
          [    1.837476] x25: 0000000000000005 x24: ffff800011f918f8
          [    1.837479] x23: ffff800011fbb588 x22: ffff0001b7e40e00
          [    1.837481] x21: 0000000000000100 x20: 0000000000000000
          [    1.837483] x19: ffff0001b767ec00 x18: 00000000ff10c000
          [    1.837485] x17: 0000000000000002 x16: 0000b0740fdb9950
          [    1.837488] x15: ffff8000116c1198 x14: ffffffffffffffff
          [    1.837490] x13: 0000000000000030 x12: 0101010101010101
          [    1.837493] x11: 0000000000000020 x10: ffff0001bf17d130
          [    1.837495] x9 : 0000000000000000 x8 : ffff0001b6938080
          [    1.837497] x7 : 0000000000000000 x6 : 000000000000003f
          [    1.837500] x5 : 0000000000000000 x4 : 0000000000000000
          [    1.837502] x3 : ffff80001096a880 x2 : 0000000000000000
          [    1.837505] x1 : ffff0001b7e40e00 x0 : 0000000100000001
          [    1.837507] Kernel panic - not syncing: Asynchronous SError Interrupt
          [    1.837509] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205
          [    1.837510] Hardware name: HiKey970 (DT)
          [    1.837511] Workqueue: events deferred_probe_work_func
          [    1.837513] Call trace:
          [    1.837514]  dump_backtrace+0x0/0x1e0
          [    1.837515]  show_stack+0x18/0x24
          [    1.837516]  dump_stack+0xc0/0x11c
          [    1.837517]  panic+0x15c/0x324
          [    1.837518]  nmi_panic+0x8c/0x90
          [    1.837519]  arm64_serror_panic+0x78/0x84
          [    1.837520]  do_serror+0x158/0x15c
          [    1.837521]  el1_error+0x84/0x100
          [    1.837522]  _raw_spin_unlock_irqrestore+0x18/0x50
          [    1.837523]  regmap_write+0x58/0x80
          [    1.837524]  hi3660_reset_deassert+0x28/0x34
          [    1.837526]  reset_control_deassert+0x50/0x260
          [    1.837527]  reset_control_deassert+0xf4/0x260
          [    1.837528]  dwc3_probe+0x5dc/0xe6c
          [    1.837529]  platform_drv_probe+0x54/0xb0
          [    1.837530]  really_probe+0xe0/0x490
          [    1.837531]  driver_probe_device+0xf4/0x160
          [    1.837532]  __device_attach_driver+0x8c/0x114
          [    1.837533]  bus_for_each_drv+0x78/0xcc
          [    1.837534]  __device_attach+0x108/0x1a0
          [    1.837535]  device_initial_probe+0x14/0x20
          [    1.837537]  bus_probe_device+0x98/0xa0
          [    1.837538]  deferred_probe_work_func+0x88/0xe0
          [    1.837539]  process_one_work+0x1cc/0x350
          [    1.837540]  worker_thread+0x2c0/0x470
          [    1.837541]  kthread+0x154/0x160
          [    1.837542]  ret_from_fork+0x10/0x30
          [    1.837569] SMP: stopping secondary CPUs
          [    1.837570] Kernel Offset: 0x1d0000 from 0xffff800010000000
          [    1.837571] PHYS_OFFSET: 0x0
          [    1.837572] CPU features: 0x240002,20882004
          [    1.837573] Memory Limit: none
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      b68d9251
    • Peter Chen's avatar
      usb: cdns3: gadget: free interrupt after gadget has deleted · 98df91f8
      Peter Chen authored
      The interrupt may occur during the gadget deletion, it fixes the
      below oops.
      
      [ 2394.974604] configfs-gadget gadget: suspend
      [ 2395.042578] configfs-gadget 5b130000.usb: unregistering UDC driver [g1]
      [ 2395.382562] irq 229: nobody cared (try booting with the "irqpoll" option)
      [ 2395.389362] CPU: 0 PID: 301 Comm: kworker/u12:6 Not tainted 5.8.0-rc3-next-20200703-00060-g2f13b83cbf30-dirty #456
      [ 2395.399712] Hardware name: Freescale i.MX8QM MEK (DT)
      [ 2395.404782] Workqueue: 2-0051 tcpm_state_machine_work
      [ 2395.409832] Call trace:
      [ 2395.412289]  dump_backtrace+0x0/0x1d0
      [ 2395.415950]  show_stack+0x1c/0x28
      [ 2395.419271]  dump_stack+0xbc/0x118
      [ 2395.422678]  __report_bad_irq+0x50/0xe0
      [ 2395.426513]  note_interrupt+0x2cc/0x38c
      [ 2395.430355]  handle_irq_event_percpu+0x88/0x90
      [ 2395.434800]  handle_irq_event+0x4c/0xe8
      [ 2395.438640]  handle_fasteoi_irq+0xbc/0x168
      [ 2395.442740]  generic_handle_irq+0x34/0x48
      [ 2395.446752]  __handle_domain_irq+0x68/0xc0
      [ 2395.450846]  gic_handle_irq+0x64/0x150
      [ 2395.454596]  el1_irq+0xb8/0x180
      [ 2395.457733]  __do_softirq+0xac/0x3b8
      [ 2395.461310]  irq_exit+0xc0/0xe0
      [ 2395.464448]  __handle_domain_irq+0x6c/0xc0
      [ 2395.468540]  gic_handle_irq+0x64/0x150
      [ 2395.472295]  el1_irq+0xb8/0x180
      [ 2395.475436]  _raw_spin_unlock_irqrestore+0x14/0x48
      [ 2395.480232]  usb_gadget_disconnect+0x120/0x140
      [ 2395.484678]  usb_gadget_remove_driver+0xb4/0xd0
      [ 2395.489208]  usb_del_gadget+0x6c/0xc8
      [ 2395.492872]  cdns3_gadget_exit+0x5c/0x120
      [ 2395.496882]  cdns3_role_stop+0x60/0x90
      [ 2395.500634]  cdns3_role_set+0x64/0xd8
      [ 2395.504301]  usb_role_switch_set_role.part.0+0x3c/0x90
      [ 2395.509444]  usb_role_switch_set_role+0x20/0x30
      [ 2395.513978]  tcpm_mux_set+0x60/0xf8
      [ 2395.517470]  tcpm_reset_port+0xa4/0xf0
      [ 2395.521222]  tcpm_detach.part.0+0x44/0x50
      [ 2395.525227]  tcpm_state_machine_work+0x8b0/0x2360
      [ 2395.529932]  process_one_work+0x1c8/0x470
      [ 2395.533939]  worker_thread+0x50/0x420
      [ 2395.537603]  kthread+0x148/0x168
      [ 2395.540830]  ret_from_fork+0x10/0x18
      [ 2395.544399] handlers:
      [ 2395.546671] [<000000008dea28da>] cdns3_wakeup_irq
      [ 2395.551375] [<000000009fee5c61>] cdns3_drd_irq threaded [<000000005148eaec>] cdns3_drd_thread_irq
      [ 2395.560255] Disabling IRQ #229
      [ 2395.563454] configfs-gadget gadget: unbind function 'Mass Storage Function'/000000000132f835
      [ 2395.563657] configfs-gadget gadget: unbind
      [ 2395.563917] udc 5b130000.usb: releasing '5b130000.usb'
      
      Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver")
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      98df91f8
    • Thinh Nguyen's avatar
      usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command · d97c78a1
      Thinh Nguyen authored
      According the programming guide (for all DWC3 IPs), when the driver
      handles ClearFeature(halt) request, it should issue CLEAR_STALL command
      _after_ the END_TRANSFER command completes. The END_TRANSFER command may
      take some time to complete. So, delay the ClearFeature(halt) request
      control status stage and wait for END_TRANSFER command completion
      interrupt. Only after END_TRANSFER command completes that the driver
      may issue CLEAR_STALL command.
      
      Cc: stable@vger.kernel.org
      Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      d97c78a1
    • Thinh Nguyen's avatar
      usb: dwc3: gadget: Resume pending requests after CLEAR_STALL · c503672a
      Thinh Nguyen authored
      The function driver may queue new requests right after halting the
      endpoint (i.e. queue new requests while the endpoint is stalled).
      There's no restriction preventing it from doing so. However, dwc3
      currently drops those requests after CLEAR_STALL. The driver should only
      drop started requests. Keep the pending requests in the pending list to
      resume and process them after the host issues ClearFeature(Halt) to the
      endpoint.
      
      Cc: stable@vger.kernel.org
      Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      c503672a
  2. 20 Sep, 2020 20 commits
  3. 19 Sep, 2020 16 commits