25 Sep, 2014

1 commit

  • Use the recently introduced usb_gadget_giveback_request() in favor of
    direct invocation of the completion routine.

    All places in drivers/usb/ matching "[-.]complete(" were replaced with a
    call to usb_gadget_giveback_request(). This was compile-tested with all
    ARM drivers enabled and runtime-tested for musb.

    Signed-off-by: Michal Sojka
    Acked-by: Felipe Balbi
    Tested-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Michal Sojka
     

10 Jul, 2014

1 commit

  • This patch fixes an issue that the renesas_usbhs driver in gadget mode
    cannot work correctly even if I disabled DMAC of the driver when I used
    the g_zero driver and the testusb tool.

    When a usb cable is re-connected, the renesas_usbhs driver calls the
    usbhsp_flags_init() (via usbhs_hotplug() --> usbhs_mod_call(start) -->
    usbhsg_try_start() --> usbhs_pipe_init()). However, the driver doesn't
    call the usbhsp_flags_init() when usbhsg_ep_disable() is called.
    So, if a gadget driver calls usb_ep_enable() and usb_ep_disable() again
    and again, the renesas_usbhs driver will output the following log:

    renesas_usbhs renesas_usbhs: can't get pipe (BULK)
    renesas_usbhs renesas_usbhs: wrong recip request

    Acked-by: Kuninori Morimoto
    Signed-off-by: Yoshihiro Shimoda
    Signed-off-by: Felipe Balbi

    Yoshihiro Shimoda
     

18 Dec, 2013

1 commit

  • This patch adds "maxpacket_limit" to struct usb_ep. This field contains
    maximum value of maxpacket supported by driver, and is set in driver probe.
    This value should be used by autoconfig() function, because value of field
    "maxpacket" is set to value from endpoint descriptor when endpoint becomes
    enabled. So when autoconfig() function will be called again for this endpoint,
    "maxpacket" value will contain wMaxPacketSize from descriptior instead of
    maximum packet size for this endpoint.

    For this reason this patch adds new field "maxpacket_limit" which contains
    value of maximum packet size (which defines maximum endpoint capabilities).
    This value is used in ep_matches() function used by autoconfig().

    Value of "maxpacket_limit" should be set in UDC driver probe function, using
    usb_ep_set_maxpacket_limit() function, defined in gadget.h. This function
    set choosen value to both "maxpacket_limit" and "maxpacket" fields.

    This patch modifies UDC drivers by adding support for maxpacket_limit.

    Signed-off-by: Robert Baldyga
    Signed-off-by: Kyungmin Park
    Signed-off-by: Felipe Balbi

    Robert Baldyga
     

29 Jul, 2013

1 commit


15 Jul, 2013

1 commit

  • usb_gadget_ops :: udc_stop might be called with driver = NULL since
    511f3c5326eabe1ece35202a404c24c0aeacc246
    (usb: gadget: udc-core: fix a regression during gadget driver unbinding)

    Because of that, 2nd times insmod goes fail.
    This patch fixes it up.

    Reported-by: Yusuke Goda
    Signed-off-by: Kuninori Morimoto
    Signed-off-by: Felipe Balbi

    Kuninori Morimoto
     

02 Apr, 2013

1 commit

  • This patch fixup below sparse errors

    CHECK ${RENESAS_USB}/common.c
    ${RENESAS_USB}/common.c:313:17: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:322:17: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:384:17: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:524:9: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:545:9: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:574:9: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/common.c:606:9: error: incompatible types in conditional expression (different base types)
    ${RENESAS_USB}/mod_gadget.c:233:28: warning: symbol 'req_clear_feature' was not declared. Should it be static?
    ${RENESAS_USB}/mod_gadget.c:274:28: warning: symbol 'req_set_feature' was not declared. Should it be static?
    ${RENESAS_USB}/mod_gadget.c:375:28: warning: symbol 'req_get_status' was not declared. Should it be static?

    [ balbi@ti.com : added three sparse fixes to mod_gadget.c ]

    Signed-off-by: Kuninori Morimoto
    Signed-off-by: Felipe Balbi

    Kuninori Morimoto
     

18 Mar, 2013

4 commits


26 Jan, 2013

1 commit

  • Felipe writes:
    usb: gadget: patches for v3.9 merge window

    finally getting rid of the old ->start()/->stop() methods
    in favor of the better and improved ->udc_start()/->udc_stop().

    There were surprisingly quite a few users left, but all of them
    have been converted.

    f_mass_storage removed some dead code, which is always great ;-)

    There's also a big cleanup to the gadget framework from Sebastian
    which gets us a lot closer to having only function drivers in
    kernel and move over to configfs-based binding.

    Other than these, there's the usual set of cleanups: s3c UDCs are
    moving over to devm_regulator_bulk_get() API, at91_udc removed
    an unnecessary check for work_pending() before scheduling and
    there's the removal of an unused variable from uac2_pcm_trigger().

    Greg Kroah-Hartman
     

25 Jan, 2013

1 commit


13 Dec, 2012

2 commits


16 Oct, 2012

1 commit


04 May, 2012

1 commit


02 Mar, 2012

1 commit

  • USB: Gadget: changes for 3.4

    This merge is rather big. Here's what it contains:

    For am5536udc we have just simple coding style fixes. Nothing that has any
    potential to cause any issues going forward.

    With mv_udc, there's only one single change removing an unneeded NULL check.

    at91_udc also only saw a single change this merge window, and that's only
    removing a duplicated header.

    The Renesas controller has a few more involved changes. Support for SUDMAC was
    added, there's now a special handling of IRQ resources for when the IRQ line is
    shared between Renesas controller and SUDMAC, we also had a bug fix where
    Renesas controller would sleep in atomic context while doing DMA transfers from
    a tasklet. There were also a set of minor cleanups.

    The FSL UDC also had a scheduling in atomic context bug fix, but that's all.

    Thanks to Sebastian, the dummy_hcd now works better than ever with support for
    scatterlists and streams. Sebastian also added SuperSpeed descriptors to the
    serial gadgets.

    The highlight on this merge is the addition of a generic API for mapping and
    unmapping usb_requests. This will avoid code duplication on all UDC controllers
    and also kills all the defines for DMA_ADDR_INVALID which UDC controllers
    sprinkled around. A few of the UDC controllers were already converted to use
    this new API.

    Conflicts:
    drivers/usb/dwc3/gadget.c

    Greg Kroah-Hartman
     

28 Feb, 2012

1 commit


24 Feb, 2012

1 commit

  • This patch fixup below warning on device_unregister()

    renesas_usbhs renesas_usbhs.1: host probed
    renesas_usbhs renesas_usbhs.1: gadget probed
    renesas_usbhs renesas_usbhs.1: irq request err
    ------------[ cut here ]------------
    WARNING: at ${LINUX}/drivers/base/core.c:1)
    Device 'gadget' does not have a release() function, it is broken and must be fi.
    Modules linked in:
    [] (unwind_backtrace+0x0/0xe4) from [] (warn_slowpath_commo)
    [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_)
    [] (warn_slowpath_fmt+0x2c/0x3c) from [] (device_release+0x)
    [] (device_release+0x70/0x84) from [] (kobject_cleanup+0x58)
    [] (kobject_cleanup+0x58/0x6c) from [] (usbhs_mod_gadget_re)
    [] (usbhs_mod_gadget_remove+0x3c/0x6c) from [] (usbhs_mod_p)
    [] (usbhs_mod_probe+0x68/0x80) from [] (usbhs_probe+0x1cc/0)
    ...

    Cc: stable@vger.kernel.org
    Signed-off-by: Kuninori Morimoto
    Signed-off-by: Felipe Balbi

    Kuninori Morimoto
     

24 Jan, 2012

1 commit

  • In drivers/usb/renesas_usbhs/mod_gadget.c::usbhsg_recip_run_handle()
    the Coverity Prevent checker currently flags a warning about possibly
    uninitialized use of 'ret' i usbhsg_recip_run_handle(). It does this
    since it assumes we take one of the non-default branches in the switch
    and then subsequently take the false branch in the 'if (func)' case
    below. This exact scenario will never happen, but Coverity can't see
    that for some reason. This patch initializes 'ret' to '0' when it is
    declared which should shut up this report and won't really hurt - so
    why not? At least then it's clear that 'ret' is always initialized..

    Signed-off-by: Jesper Juhl
    Signed-off-by: Felipe Balbi

    Jesper Juhl
     

15 Dec, 2011

1 commit

  • Gcc complains about this printk:
    drivers/usb/renesas_usbhs/mod_gadget.c:188:3: warning: format ‘%x’
    expects argument of type ‘unsigned int’, but argument 3 has type
    ‘dma_addr_t’ [-Wformat]

    Signed-off-by: Dan Carpenter
    Signed-off-by: Felipe Balbi

    Dan Carpenter
     

13 Dec, 2011

1 commit

  • driver has to re-use the limited pipe for each device/endpoint
    when it is USB host hub mode, since number of pipe has limitation.

    Then, each pipe should care own pipe sequence for next packet.
    This patch adds sequence control.

    Signed-off-by: Kuninori Morimoto
    Signed-off-by: Felipe Balbi

    Kuninori Morimoto
     

12 Dec, 2011

11 commits


29 Nov, 2011

4 commits


15 Nov, 2011

1 commit

  • Fix up the following section mismatch warnings:

    WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xf5d): Section
    mismatch in reference from the function usbhs_mod_probe() to the function
    .devinit.text:usbhs_mod_host_probe() The function usbhs_mod_probe() references
    the function __devinit usbhs_mod_host_probe(). This is often because
    usbhs_mod_probe lacks a __devinit annotation or the annotation of
    usbhs_mod_host_probe is wrong.

    WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xfd7): Section
    mismatch in reference from the function usbhs_mod_probe() to the function
    .devexit.text:usbhs_mod_host_remove() The function usbhs_mod_probe() references
    a function in an exit section. Often the function usbhs_mod_host_remove() has
    valid usage outside the exit section and the fix is to remove the __devexit
    annotation of usbhs_mod_host_remove.

    WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0x1005): Section
    mismatch in reference from the function usbhs_mod_remove() to the function
    .devexit.text:usbhs_mod_host_remove() The function usbhs_mod_remove()
    references a function in an exit section. Often the function
    usbhs_mod_host_remove() has valid usage outside the exit section and the fix is
    to remove the __devexit annotation of usbhs_mod_host_remove.

    Signed-off-by: Kuninori Morimoto
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Kuninori Morimoto
     

14 Oct, 2011

2 commits