12 May, 2020

8 commits

  • It is better to re-init request list for EP0 when the EP0 begins to
    uses.

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • The new usb_gadget_disconnect API includes both calling class
    driver's disconnect and calling .pullup at udc driver, so we
    could simply your udc driver handling.

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • We do not want to handle any interrupts after usb_gadget_disconnect
    is called.

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • Below is the recommendation from Cadence designer:
    Using this bit to be sure that PHY clock is keeping up in active
    state. It's good to keep Fast Access bit enabled as long as there
    is any access to USB register.

    It is used to fix the potential ARM core hang when visit controller
    register after DEVDS is set.

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • And there are no multiple TRBs on EP0 and WA1 workaround,
    so it doesn't need to change TRB for EP0. It fixes below oops.

    configfs-gadget gadget: high-speed config #1: b
    android_work: sent uevent USB_STATE=CONFIGURED
    Unable to handle kernel read from unreadable memory at virtual address 0000000000000008
    Mem abort info:
    android_work: sent uevent USB_STATE=DISCONNECTED
    ESR = 0x96000004
    EC = 0x25: DABT (current EL), IL = 32 bits

    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    Data abort info:
    ISV = 0, ISS = 0x00000004
    CM = 0, WnR = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b5bb7000
    [0000000000000008] pgd=0000000000000000
    Internal error: Oops: 96000004 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 2 PID: 430 Comm: HwBinder:401_1 Not tainted 5.4.24-06071-g6fa8921409c1-dirty #77
    Hardware name: Freescale i.MX8QXP MEK (DT)
    pstate: 60400085 (nZCv daIf +PAN -UAO)
    pc : cdns3_gadget_ep_dequeue+0x1d4/0x270
    lr : cdns3_gadget_ep_dequeue+0x48/0x270
    sp : ffff800012763ba0
    x29: ffff800012763ba0 x28: ffff00082c653c00
    x27: 0000000000000000 x26: ffff000068fa7b00
    x25: ffff0000699b2000 x24: ffff00082c6ac000
    x23: ffff000834f0a480 x22: ffff000834e87b9c
    x21: 0000000000000000 x20: ffff000834e87800
    x19: ffff000069eddc00 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000
    x15: 0000000000000000 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000001
    x11: ffff80001180fbe8 x10: 0000000000000001
    x9 : ffff800012101558 x8 : 0000000000000001
    x7 : 0000000000000006 x6 : ffff000835d9c668
    x5 : ffff000834f0a4c8 x4 : 0000000096000000
    x3 : 0000000000001810 x2 : 0000000000000000
    x1 : ffff800024bd001c x0 : 0000000000000001
    Call trace:
    cdns3_gadget_ep_dequeue+0x1d4/0x270
    usb_ep_dequeue+0x34/0xf8
    composite_dev_cleanup+0x154/0x170
    configfs_composite_unbind+0x6c/0xa8
    usb_gadget_remove_driver+0x44/0x70
    usb_gadget_unregister_driver+0x74/0xe0
    unregister_gadget+0x28/0x58
    gadget_dev_desc_UDC_store+0x80/0x110
    configfs_write_file+0x1e0/0x2a0
    __vfs_write+0x48/0x90
    vfs_write+0xe4/0x1c8
    ksys_write+0x78/0x100
    __arm64_sys_write+0x24/0x30
    el0_svc_common.constprop.0+0x74/0x168
    el0_svc_handler+0x34/0xa0
    el0_svc+0x8/0xc
    Code: 52830203 b9407660 f94042e4 11000400 (b9400841)
    ---[ end trace 1574516e4c1772ca ]---
    Kernel panic - not syncing: Fatal exception
    SMP: stopping secondary CPUs
    Kernel Offset: disabled
    CPU features: 0x0002,20002008
    Memory Limit: none
    Rebooting in 5 seconds..

    Fixes: f616c3bda47e ("usb: cdns3: Fix dequeue implementation")
    Cc: stable
    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • Assign interrupt number to USB gadget structure.

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • The threaded interrupt handler may still be called after the
    usb_gadget_disconnect is called, it causes the structures used
    at interrupt handler was freed before it uses, eg the
    usb_request. This issue usually occurs we remove the udc function
    during the transfer. Below is the example when doing stress
    test for android switch function, the EP0's request is freed
    by .unbind (configfs_composite_unbind -> composite_dev_cleanup),
    but the threaded handler accesses this request during handling
    setup packet request.

    In fact, there is no protection between unbind the udc
    and udc interrupt handling, so we have to avoid the interrupt
    handler is occurred or scheduled during the .unbind flow.

    init: Sending signal 9 to service 'adbd' (pid 18077) process group...
    android_work: did not send uevent (0 0 000000007bec2039)
    libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms
    init: Service 'adbd' (pid 18077) received signal 9
    init: Sending signal 9 to service 'adbd' (pid 18077) process group...
    libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms
    init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14)
    init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1.

    init: starting service 'adbd'...
    read descriptors
    read strings
    Unable to handle kernel read from unreadable memory at virtual address 000000000000002a
    android_work: sent uevent USB_STATE=CONNECTED
    Mem abort info:
    ESR = 0x96000004
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    Data abort info:
    ISV = 0, ISS = 0x00000004
    CM = 0, WnR = 0
    user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000
    using random self ethernet address
    [000000000000002a] pgd=0000000000000000
    Internal error: Oops: 96000004 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 #92
    Hardware name: Freescale i.MX8QXP MEK (DT)
    pstate: 00400085 (nzcv daIf +PAN -UAO)
    using random host ethernet address
    pc : composite_setup+0x5c/0x1730
    lr : android_setup+0xc0/0x148
    sp : ffff80001349bba0
    x29: ffff80001349bba0 x28: ffff00083a50da00
    x27: ffff8000124e6000 x26: ffff800010177950
    x25: 0000000000000040 x24: ffff000834e18010
    x23: 0000000000000000 x22: 0000000000000000
    x21: ffff00083a50da00 x20: ffff00082e75ec40
    x19: 0000000000000000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000
    x15: 0000000000000000 x14: 0000000000000000
    x13: 0000000000000000 x12: 0000000000000001
    x11: ffff80001180fb58 x10: 0000000000000040
    x9 : ffff8000120fc980 x8 : 0000000000000000
    x7 : ffff00083f98df50 x6 : 0000000000000100
    x5 : 00000307e8978431 x4 : ffff800011386788
    x3 : 0000000000000000 x2 : ffff800012342000
    x1 : 0000000000000000 x0 : ffff800010c6d3a0
    Call trace:
    composite_setup+0x5c/0x1730
    android_setup+0xc0/0x148
    cdns3_ep0_delegate_req+0x64/0x90
    cdns3_check_ep0_interrupt_proceed+0x384/0x738
    cdns3_device_thread_irq_handler+0x124/0x6e0
    cdns3_thread_irq+0x94/0xa0
    irq_thread_fn+0x30/0xa0
    irq_thread+0x150/0x248
    kthread+0xfc/0x128
    ret_from_fork+0x10/0x18
    Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61)
    ---[ end trace c685db37f8773fba ]---
    Kernel panic - not syncing: Fatal exception
    SMP: stopping secondary CPUs
    Kernel Offset: disabled
    CPU features: 0x0002,20002008
    Memory Limit: none
    Rebooting in 5 seconds..

    Reviewed-by: Jun Li
    Signed-off-by: Peter Chen

    Peter Chen
     
  • EP command will use suspend_clk(32K) if the SS PHY is at P3,
    this slow clock makes EP command need more time to complete,
    1000 times register read is not enough in this case, will
    generate timeout like below:

    dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
    params 00001000 00000500 00000000 --> status: Timed Out

    Success case takes about 400us to complete, see below trace
    (44.286278 - 44.285897 = 0.000381s):

    configfs_acm.sh-822 [000] d..1 44.285896: dwc3_writel:
    addr 000000006d59aae1 value 00000401
    configfs_acm.sh-822 [000] d..1 44.285897: dwc3_readl:
    addr 000000006d59aae1 value 00000401
    ... ...
    configfs_acm.sh-822 [000] d..1 44.286278: dwc3_readl:
    addr 000000006d59aae1 value 00000001
    configfs_acm.sh-822 [000] d..1 44.286279: dwc3_gadget_ep_cmd:
    ep0out: cmd 'Set Endpoint Configuration' [401]
    params 00001000 00000500 00000000 --> status: Successful

    Reviewed-by: Peter Chen
    Signed-off-by: Li Jun
    (cherry picked from commit ed138303c1fcd87a30e0b37336b0d8993f4e5e38)

    Li Jun
     

06 May, 2020

1 commit

  • Since the typec port data role is separated from power role,
    so check the port data capability when setting data role.

    Signed-off-by: Li Jun
    Reviewed-by: Heikki Krogerus
    Link: https://lore.kernel.org/r/1581666828-2063-1-git-send-email-jun.li@nxp.com
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit 6ecc632d4b35d24c443d3c3b797aa204cc5c4ab1)

    Li Jun
     

29 Apr, 2020

1 commit

  • commit 9f952e26295d977dbfc6fedeaf8c4f112c818d37 upstream.

    Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event
    during reset-resume") wasn't very well conceived. The problem it
    tried to fix was that if a connect-change event occurred while the
    system was asleep (such as a device disconnecting itself from the bus
    when it is suspended and then reconnecting when it resumes)
    requiring a reset-resume during the system wakeup transition, the hub
    port's change_bit entry would remain set afterward. This would cause
    the hub driver to believe another connect-change event had occurred
    after the reset-resume, which was wrong and would lead the driver to
    send unnecessary requests to the device (which could interfere with a
    firmware update).

    The commit tried to fix this by not setting the change_bit during the
    wakeup. But this was the wrong thing to do; it means that when a
    device is unplugged while the system is asleep, the hub driver doesn't
    realize anything has happened: The change_bit flag which would tell it
    to handle the disconnect event is clear.

    The commit needs to be reverted and the problem fixed in a different
    way. Fortunately an alternative solution was noted in the commit's
    Changelog: We can continue to set the change_bit entry in
    hub_activate() but then clear it when a reset-resume occurs. That way
    the the hub driver will see the change_bit when a device is
    disconnected but won't see it when the device is still present.

    That's what this patch does.

    Reported-and-tested-by: Peter Chen
    Signed-off-by: Alan Stern
    Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume")
    Tested-by: Paul Zimmerman
    CC:
    Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2FPine.LNX.4.44L0.2004221602480.11262-100000%40iolanthe.rowland.org&data=02%7C01%7Cpeter.chen%40nxp.com%7C0c4a073d13d44cd9bb3a08d7eba40fdd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637236962191385194&sdata=gGE2I8VS%2BT2%2BrssNXoPaUKtBIk7WgnVMka7KhiGpWLA%3D&reserved=0
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     

27 Apr, 2020

2 commits

  • In cdns3_transfer_completed, it uses is_short to judge if current
    request is short transfer to calculate req->actual correctly, but
    is_short variable may for previous transfer, it causes req->actual
    calculation wrong for current transfer. Eg, the previous transfer is
    non-short tranfer, and the current one is short transfer, the req->actual
    will accumulate the non-transfered TRB's length.

    In fact, below condition already stands for short trasnfer for scatter
    list:

    if (priv_req->num_of_trb > 1 &&
    le32_to_cpu(trb->control) & TRB_SMM)

    So we could (need) to delete the parameter 'is_short'

    Reviewed-by: Jun Li
    Reported-by: Faqiang Zhu
    Signed-off-by: Peter Chen

    Peter Chen
     
  • For each request, it needs to clear transfer_end, otherwise,
    the second transfer's actual transfer length will not
    report to class driver if the first transfer is short and both
    the two transfers are handled in the same threaded irq handler.

    Reviewed-by: Jun Li
    Reported-by: Faqiang Zhu
    Signed-off-by: Peter Chen

    Peter Chen
     

03 Apr, 2020

1 commit


31 Mar, 2020

11 commits


27 Mar, 2020

5 commits


19 Mar, 2020

5 commits


17 Mar, 2020

2 commits


15 Mar, 2020

3 commits

  • As role switch class does not use otg irq like edev, so don't
    do free irq for it.

    Reviewed-by: Peter Chen
    Acked-by: Fugang Duan
    Signed-off-by: Li Jun
    (cherry picked from commit fd263a3edd95dfe812397fabf1059b5f99bba2ab)

    Li Jun
     
  • As driver removal will do clocks disable, we don't need runtime
    suspend to disable clocks, so keep runtime resume when driver
    remove.

    Reviewed-by: Peter Chen
    Reviewed-by: Fugang Duan
    Signed-off-by: Li Jun
    (cherry picked from commit 24b9a59b32127af6e217e56490d643f39ca6ff60)

    Li Jun
     
  • If we're in the middle of series of chained TRBs and we
    receive a short transfer along the way, DWC3 will skip
    through all TRBs including the last TRB in the chain, DWC3
    will avoid clearing HWO bit and SW has to do it manually.
    but currect code can't hit the condition when loop sgs of
    request in dwc3_gadget_ep_reclaim_trb_sg() if short packet
    received for one chained trb, because it only check the HWO
    bit of all trbs and then break if it's 1, so the remain trbs
    has no chance to be handled by dwc3_gadget_ep_reclaim_completed_trb(),
    this patch adds a flag if received a short packet in a chained
    trb, and let dwc3_gadget_ep_reclaim_trb_sg() continue handle
    all trbs and give back to function driver.

    Reviewed-by: Peter Chen
    Signed-off-by: Li Jun

    Li Jun
     

10 Mar, 2020

1 commit

  • If scatter-gather operation is allowed, a large USB request is split
    into multiple TRBs. For preparing TRBs for sg list, driver iterates
    over the list and creates TRB for each sg and mark the chain bit to
    false for the last sg. The current IOMMU driver is clubbing the list
    of sgs which shares a page boundary into one and giving it to USB driver.
    With this the number of sgs mapped it not equal to the the number of sgs
    passed. Because of this USB driver is not marking the chain bit to false
    since it couldn't iterate to the last sg. This patch addresses this issue
    by marking the chain bit to false if it is the last mapped sg.

    At a practical level, this patch resolves USB transfer stalls
    seen with adb on dwc3 based db845c, pixel3 and other qcom
    hardware after functionfs gadget added scatter-gather support
    around v4.20.

    Credit also to Anurag Kumar Vulisha
    who implemented a very similar fix to this issue.

    Cc: Felipe Balbi
    Cc: Yang Fei
    Cc: Thinh Nguyen
    Cc: Tejas Joglekar
    Cc: Andrzej Pietrasiewicz
    Cc: Jack Pham
    Cc: Todd Kjos
    Cc: Greg KH
    Cc: Linux USB List
    Cc: stable
    Signed-off-by: Pratham Pratap
    [jstultz: Slight tweak to remove sg_is_last() usage, reworked
    commit message, minor comment tweak]
    Signed-off-by: John Stultz

    Pratham Pratap