Kmemleak checking configuration reports a memory leak in
usb_os_desc_prepare_interf_dir function when rndis function
instance is freed and then allocated again. For example, this
happens with FunctionFS driver with RNDIS function enabled
when "ffs-test" test application is run several times in a row.

The data for intermediate "os_desc" group for interface directories
is allocated as a single VLA chunk and (after a change of default
groups handling) is not ever freed and actually not stored anywhere
besides inside a list of default groups of a parent group.

The fix is to make usb_os_desc_prepare_interf_dir function return
a pointer to allocated data (as a pointer to the first VLA item)
instead of (an unused) integer and to make the caller component
(currently the only one is RNDIS function) responsible for storing
the pointer and freeing the memory when appropriate.

Fixes: 1ae1602d ("configfs: switch ->default groups to a linked list")
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

KASAN enabled configuration reports an error

    BUG: KASAN: use-after-free in usb_composite_overwrite_options+...
                [libcomposite] at addr ...
    Read of size 1 by task ...

when some driver is un-bound and then bound again.
For example, this happens with FunctionFS driver when "ffs-test"
test application is run several times in a row.

If the driver has empty manufacturer ID string in initial static data,
it is then replaced with generated string. After driver unbinding
the generated string is freed, but the driver data still keep that
pointer. And if the driver is then bound again, that pointer
is re-used for string emptiness check.

The fix is to clean up the driver string data upon its unbinding
to drop the pointer to freed memory.

Fixes: cc2683c3 ("usb: gadget: Provide a default implementation of default manufacturer string")
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The dummy-hcd driver calls the gadget driver's disconnect callback
under the wrong conditions.  It should invoke the callback when Vbus
power is turned off, but instead it does so when the D+ pullup is
turned off.

This can cause a deadlock in the composite core when a gadget driver
is unregistered:

[   88.361471] ============================================
[   88.362014] WARNING: possible recursive locking detected
[   88.362580] 4.14.0-rc2+ #9 Not tainted
[   88.363010] --------------------------------------------
[   88.363561] v4l_id/526 is trying to acquire lock:
[   88.364062]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite]
[   88.365051]
[   88.365051] but task is already holding lock:
[   88.365826]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.366858]
[   88.366858] other info that might help us debug this:
[   88.368301]  Possible unsafe locking scenario:
[   88.368301]
[   88.369304]        CPU0
[   88.369701]        ----
[   88.370101]   lock(&(&cdev->lock)->rlock);
[   88.370623]   lock(&(&cdev->lock)->rlock);
[   88.371145]
[   88.371145]  *** DEADLOCK ***
[   88.371145]
[   88.372211]  May be due to missing lock nesting notation
[   88.372211]
[   88.373191] 2 locks held by v4l_id/526:
[   88.373715]  #0:  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.374814]  #1:  (&(&dum_hcd->dum->lock)->rlock){....}, at: [<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[   88.376289]
[   88.376289] stack backtrace:
[   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[   88.379504] Call Trace:
[   88.380019]  dump_stack+0x86/0xc7
[   88.380605]  __lock_acquire+0x841/0x1120
[   88.381252]  lock_acquire+0xd5/0x1c0
[   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
[   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
[   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
[   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
[   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
[   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
[   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
[   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]

This patch changes the code to test the port-power status bit rather
than the port-connect status bit when deciding whether to isue the
callback.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Tulloh <david@tulloh.id.au>
CC: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The driver triggers actions on both edges of the vbus signal.

The former PIO controller was triggering IRQs on both falling and rising edges
by default. Newer PIO controller don't, so it's better to set it explicitly to
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.

Without this patch we may trigger the connection with host but only on some
bouncing signal conditions and thus lose connecting events.
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Cc: stable <stable@vger.kernel.org> # v4.4+
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

By submitting completed transfers to the system workqueue there is no
guarantee that completion events will be queued up in the correct order,
as in multi-processor systems there is a thread running for each
processor and the work items are not bound to a particular core.

This means that several completions are in the queue at the same time,
they may be processed in parallel and complete out of order, resulting
in data appearing corrupt when read by userspace.

Create a single-threaded workqueue for FunctionFS so that data completed
requests is passed to userspace in the order in which they complete.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NJohn Keeping <john@metanate.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch fixes an issue that this driver cannot go status stage
in control read when the req.zero is set to 1 and the len in
usb3_write_pipe() is set to 0. Otherwise, if we use g_ncm driver,
usb enumeration takes long time (5 seconds or more).

Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

According to the datasheet of R-Car Gen3, the Pn_RAMMAP.Pn_MPKT should
be set to one of 8, 16, 32, 64, 512 and 1024. Otherwise, when a gadget
driver uses an interrupt endpoint, unexpected behavior happens. So,
this patch fixes it.

Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When bRequestType & USB_DIR_IN is false and req.length is 0 in control
transfer, since it means non-data, this driver should not set the mode
as control write. So, this patch fixes it.

Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

A recent change to the synchronization in dummy-hcd was incorrect.
The issue was that dummy_udc_stop() contained no locking and therefore
could race with various gadget driver callbacks, and the fix was to
add locking and issue the callbacks with the private spinlock held.

UDC drivers aren't supposed to do this.  Gadget driver callback
routines are allowed to invoke functions in the UDC driver, and these
functions will generally try to acquire the private spinlock.  This
would deadlock the driver.

The correct solution is to drop the spinlock before issuing callbacks,
and avoid races by emulating the synchronize_irq() call that all real
UDC drivers must perform in their ->udc_stop() routines after
disabling interrupts.  This involves adding a flag to dummy-hcd's
private structure to keep track of whether interrupts are supposed to
be enabled, and adding a counter to keep track of ongoing callbacks so
that dummy_udc_stop() can wait for them all to finish.

A real UDC driver won't receive disconnect, reset, suspend, resume, or
setup events once it has disabled interrupts.  dummy-hcd will receive
them but won't try to issue any gadget driver callbacks, which should
be just as good.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Fixes: f16443a0 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
CC: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The dummy-hcd HCD/UDC emulator tries not to do too much work during
each timer interrupt.  But it doesn't try very hard; currently all
it does is limit the total amount of bulk data transferred.  Other
transfer types aren't limited, and URBs that transfer no data (because
of an error, perhaps) don't count toward the limit, even though on a
real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop,
for example, if the host class driver resubmits an URB every time it
completes (which is common for interrupt URBs).  Each time the URB is
resubmitted it gets added to the end of the pending-URBs list, and
dummy-hcd doesn't stop until that list is empty.  Andrey Konovalov was
able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs
handled during each timer interrupt to those that were already on the
pending list when the interrupt routine started.  Newly added URBs
won't be processed until the next timer interrupt.  The problem of
properly accounting for non-bulk bandwidth (as well as packet and
transaction overhead) is not addressed here.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The dummy-hcd UDC driver is not careful about the way it handles
connection speeds.  It ignores the module parameter that is supposed
to govern the maximum connection speed and it doesn't set the HCD
flags properly for the case where it ends up running at full speed.

The result is that in many cases, gadget enumeration over dummy-hcd
fails because the bMaxPacketSize byte in the device descriptor is set
incorrectly.  For example, the default settings call for a high-speed
connection, but the maxpacket value for ep0 ends up being set for a
Super-Speed connection.

This patch fixes the problem by initializing the gadget's max_speed
and the HCD flags correctly.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As a holdover from the old g_file_storage gadget, the g_mass_storage
legacy gadget driver attempts to unregister itself when its main
operating thread terminates (if it hasn't been unregistered already).
This is not strictly necessary; it was never more than an attempt to
have the gadget fail cleanly if something went wrong and the main
thread was killed.

However, now that the UDC core manages gadget drivers independently of
UDC drivers, this scheme doesn't work any more.  A simple test:

	modprobe dummy-hcd
	modprobe g-mass-storage file=...
	rmmod dummy-hcd

ends up in a deadlock with the following backtrace:

 sysrq: SysRq : Show Blocked State
   task                PC stack   pid father
 file-storage    D    0  1130      2 0x00000000
 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_preempt_disabled+0xd/0xf
  __mutex_lock.isra.1+0x129/0x224
  ? _raw_spin_unlock_irqrestore+0x12/0x14
  __mutex_lock_slowpath+0x12/0x14
  mutex_lock+0x28/0x2b
  usb_gadget_unregister_driver+0x29/0x9b [udc_core]
  usb_composite_unregister+0x10/0x12 [libcomposite]
  msg_cleanup+0x1d/0x20 [g_mass_storage]
  msg_thread_exits+0xd/0xdd7 [g_mass_storage]
  fsg_main_thread+0x1395/0x13d6 [usb_f_mass_storage]
  ? __schedule+0x573/0x58c
  kthread+0xd9/0xdb
  ? do_set_interface+0x25c/0x25c [usb_f_mass_storage]
  ? init_completion+0x1e/0x1e
  ret_from_fork+0x19/0x24
 rmmod           D    0  1155    683 0x00000000
 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_timeout+0x26/0xbc
  ? __schedule+0x573/0x58c
  do_wait_for_common+0xb3/0x128
  ? usleep_range+0x81/0x81
  ? wake_up_q+0x3f/0x3f
  wait_for_common+0x2e/0x45
  wait_for_completion+0x17/0x19
  fsg_common_put+0x34/0x81 [usb_f_mass_storage]
  fsg_free_inst+0x13/0x1e [usb_f_mass_storage]
  usb_put_function_instance+0x1a/0x25 [libcomposite]
  msg_unbind+0x2a/0x42 [g_mass_storage]
  __composite_unbind+0x4a/0x6f [libcomposite]
  composite_unbind+0x12/0x14 [libcomposite]
  usb_gadget_remove_driver+0x4f/0x77 [udc_core]
  usb_del_gadget_udc+0x52/0xcc [udc_core]
  dummy_udc_remove+0x27/0x2c [dummy_hcd]
  platform_drv_remove+0x1d/0x31
  device_release_driver_internal+0xe9/0x16d
  device_release_driver+0x11/0x13
  bus_remove_device+0xd2/0xe2
  device_del+0x19f/0x221
  ? selinux_capable+0x22/0x27
  platform_device_del+0x21/0x63
  platform_device_unregister+0x10/0x1a
  cleanup+0x20/0x817 [dummy_hcd]
  SyS_delete_module+0x10c/0x197
  ? ____fput+0xd/0xf
  ? task_work_run+0x55/0x62
  ? prepare_exit_to_usermode+0x65/0x75
  do_fast_syscall_32+0x86/0xc3
  entry_SYSENTER_32+0x4e/0x7c

What happens is that removing the dummy-hcd driver causes the UDC core
to unbind the gadget driver, which it does while holding the udc_lock
mutex.  The unbind routine in g_mass_storage tells the main thread to
exit and waits for it to terminate.

But as mentioned above, when the main thread exits it tries to
unregister the mass-storage function driver.  Via the composite
framework this ends up calling usb_gadget_unregister_driver(), which
tries to acquire the udc_lock mutex.  The result is deadlock.

The simplest way to fix the problem is not to be so clever: The main
thread doesn't have to unregister the function driver.  The side
effects won't be so terrible; if the gadget is still attached to a USB
host when the main thread is killed, it will appear to the host as
though the gadget's firmware has crashed -- a reasonably accurate
interpretation, and an all-too-common occurrence for USB mass-storage
devices.

In fact, the code to unregister the driver when the main thread exits
is specific to g-mass-storage; it is not used when f-mass-storage is
included as a function in a larger composite device.  Therefore the
entire mechanism responsible for this (the fsg_operations structure
with its ->thread_exits method, the fsg_common_set_ops() routine, and
the msg_thread_exits() callback routine) can all be eliminated.  Even
the msg_registered bitflag can be removed, because now the driver is
unregistered in only one place rather than in two places.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written
before the UDC and composite frameworks were adopted; it is a legacy
driver.  As such, it expects that once bound to a UDC controller, it
will not be unbound until it unregisters itself.

However, the UDC framework does unbind function drivers while they are
still registered.  When this happens, it can cause the gadgetfs driver
to misbehave or crash.  For example, userspace can cause a crash by
opening the device file and doing an ioctl call before setting up a
configuration (found by Andrey Konovalov using the syzkaller fuzzer).

This patch adds checks and synchronization to prevent these bad
behaviors.  It adds a udc_usage counter that the driver increments at
times when it is using a gadget interface without holding the private
spinlock.  The unbind routine waits for this counter to go to 0 before
returning, thereby ensuring that the UDC is no longer in use.

The patch also adds a check in the dev_ioctl() routine to make sure
the driver is bound to a UDC before dereferencing the gadget pointer,
and it makes destroy_ep_files() synchronize with the endpoint I/O
routines, to prevent the user from accessing an endpoint data
structure after it has been removed.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The gadgetfs driver as a long-outstanding FIXME, regarding a call of
copy_to_user() made while holding a spinlock.  This patch fixes the
issue by dropping the spinlock and using the dev->udc_usage mechanism
introduced by another recent patch to guard against status changes
while the lock isn't held.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:

drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
         USB_PORT_STAT_ENABLE) == 1 &&
                               ^~
drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
      USB_SS_PORT_LS_U0) == 1 &&
                         ^~

I looked at the code for a bit and came up with a change that makes
it look like what the author probably meant here. This makes it
look reasonable to me and to gcc, shutting up the warning.

It does of course change behavior as the two conditions are actually
evaluated rather than being hardcoded to false, and I have made no
attempt at verifying that the changed logic makes sense in the context
of a USB HCD, so that part needs to be reviewed carefully.

Fixes: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support")
Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Cc: Felipe Balbi <balbi@kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Fix build errors that happen when CONFIG_EXTCON=m and
CONFIG_USB_SNP_UDC_PLAT=y by preventing that combination in Kconfig.
CONFIG_EXTCON can still be disabled or enabled for this driver since
<linux/extcon.h> has stubs for the disabled case, but if CONFIG_EXTCON=m,
USB_SNP_UDC_PLAT is restricted to m or n (cannot be builtin).

drivers/built-in.o: In function `udc_plat_remove':
snps_udc_plat.c:(.text+0x2c4060): undefined reference to `extcon_unregister_notifier'
drivers/built-in.o: In function `udc_plat_probe':
snps_udc_plat.c:(.text+0x2c438c): undefined reference to `extcon_get_edev_by_phandle'
snps_udc_plat.c:(.text+0x2c43f2): undefined reference to `extcon_register_notifier'
snps_udc_plat.c:(.text+0x2c4416): undefined reference to `extcon_get_state'
snps_udc_plat.c:(.text+0x2c44f7): undefined reference to `extcon_unregister_notifier'
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If usb_gadget_giveback_request() is called in usb_ep_queue(),
this printer_write() is possible to cause spinlock recursion. So,
this patch adds spin_unlock() before calls usb_ep_queue() to avoid it.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Consider the following case: udc controller supports SuperSpeed.  If we
first load a HighSpeed gadget followed by a SuperSpeed gadget, the
SuperSpeed gadget will be limited to HighSpeed as UDC core driver
doesn't call ->udc_set_speed() in the second case.

Call ->udc_set_speed() unconditionally to fix this issue.

This will also fix the case for dwc3 controller driver when SuperSpeed
gadget is loaded first and works in HighSpeed only as udc_set_speed()
was never being called.

Fixes: 6099eca796ae ("usb: gadget: core: introduce ->udc_set_speed() method")
Cc: <stable@vger.kernel.org> [v4.13+]
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead use kernel_read/write consistently, which also makes sparse
happy.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Make this const as it is only used during a copy operation.
Done using Coccinelle.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

That quirk is required to make USB Ethernet gadget working on HW that
can't cope with unaligned DMA. For some reason only f_ncm sets up that
quirk, let's setup it directly in u_ether so other network models would
have that quirk applied as well. All network models have been tested with
ChipIdea UDC driver on NVIDIA Tegra20 SoC that require DMA to be aligned.
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack of
gadget serial device to TTY association (i.e. a NULL pointer dereference).
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The usb_add_gadget_udc_release() routine in the USB gadget core will
sometimes but not always call the gadget's release function when an
error occurs.  More specifically, if the struct usb_udc allocation
fails then the release function is not called, and for other errors it
is.

As a result, users of this routine cannot know whether they need to
deallocate the memory containing the gadget structure following an
error.  This leads to unavoidable memory leaks or double frees.

This patch fixes the problem by splitting the existing
device_register() call into device_initialize() and device_add(), and
doing the udc allocation in between.  That way, even if the allocation
fails it is still possible to call device_del(), and so the release
function will be always called following an error.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>

Users can apply i/o in the wrong direction on an
endpoint to stall it. In case there is an error
that does not allow the endpoint to be stalled,
we want the user to know.

An operation to stall the endpoint will return
EBADMSG if successful, EAGAIN if there are still
queued requests, and other errors depending on
the underlying implementation.

Also remove the conditional since it is always true.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NJerry Zhang <zhangjerry@google.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If a phy is specified in the device tree node, get it and use it.
This was based on a patch by:
"Srinath Mannam <srinath.mannam@broadcom.com>"
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Many ARM based Broadcom STB SoC's have a USB BDC controller so
enable this driver for these systems.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch essentially clears the port status change bits at the
correct times. It is necessary because the driver was not handling
the change bits correctly for events during device
connection/disconnection and bus enumeration. So, one of them (PCC)
was left stuck sometimes causing the "xsf for ep not enabled"
error we get on first connection. This was found by the Android team.
This was debugged and fixed by Sasi Kumar.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Based on a previous commit by Danesh Petigara <dpetigara@broadcom.com>
that added resume to solve the following problem:
"The BDC driver will fail after resuming from S3 suspend and this
will cause any upper layer gadget driver to fail."
This commit also adds support for suspend and manages the clock during
suspend/resume.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Allows Device Tree probing
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Newer SoC's have added a BDC clock to the Device Tree, so get
and enable it.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The BDC endpoint status registers 0-7 were originally each going
to be an array of regsiters. This was later changed to being a
single register. The register definitions are being changed from:
"#define BDC_EPSTS0(n)  (0x60 + (n * 0x10))"
to
"#define BDC_EPSTS0	0x60"
to reflect this change and to avoid future coding mistakes.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This adds 3 new options to the RNDIS gadget function configs. It allows
overriding the default USB interface class/subclass/protocol.

The motivation for this is that if you set the values to "ef" (Misc),
"04" (RNDIS), "01" (Ethernet) respectively, then the device will be
recognized by the rndiscmp.inf file in Windows Vista and newer and will
cause Windows to load the correct RNDIS driver without the need for a
custom (signed) .inf file.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In the SG case this is already handled since a non-zero
request->num_mapped_sgs is a clear indicator that dma_map_sg()
had been called. While it would be nice to do the same for the
singly mapped case by simply checking for non-zero request->dma,
it's conceivable that 0 is a valid dma_addr_t handle. Hence add
a flag 'dma_mapped' to struct usb_request and use this to
determine the need to call dma_unmap_single(). Otherwise, if a
request is not DMA mapped then the result of calling
usb_request_unmap_request() would safely be a no-op.
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

USB gadget serial console works on functions other than the legacy
configurations. Let the user enable it when using any function that
uses the serial utilities.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@cascardo.eti.br>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Make the structure const as it is only stored in the ops field of a
usb_ep structure, which is of type const.
Done using Coccinelle.
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Currenly, f_midi_free uses snd_card_free, which will wait
until the user has released the sound card before
returning. However, if the user doesn't release the sound
card, then f_midi_free can block for an arbitrary amount
of time, which also blocks any gadget operations on that
thread.

Instead, we can use snd_card_free_when_closed which returns
before all handles are released. Since f_midi can be
accessed through rmidi if usb_put_function is called before
release_card_device, add refcounting to f_midi_free and
have rawmidi's private free call it. The f_midi memory
is only kfreed when usb_put_function and release_card_device
have both been called.
Signed-off-by: NJerry Zhang <zhangjerry@google.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add super speed descriptors for f_midi.
Signed-off-by: NBadhri Jagan Sridharan <Badhri@google.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The while loop never terminates because the loop counter i is never
decremented. Fix this by decrementing i.

Detected by CoverityScan, CID#751073 ("Infinite Loop")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>