Attach strings to gadget with usb_strings_attach.
It is required for correct instantiation of functions more than once:
instead of modifying the local uvc_en_us_strings a function instance
specific copy is created with usb_gstrings_attach.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There are no users of the old interface left. Remove it.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the new function interface of f_uvc.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Use the new function registration interface. It is required
in order to integrate configfs support.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
[Updated copyright years]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Compile uvc_queue, uvc_v4l2, uvc_video separately so that later they can
be all combined in a separately compiled f_uvc.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
[Make uvc_v4l2_ioctl_ops non-static]
[Rename __UVC__V4L2__H__ and __UVC__VIDEO__H__]
[Update MAINTAINERS]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Prepare for separate compilation of uvc function's components.
Some symbols will have to be exported, so rename to avoid
conflicts with functions of the same name in host uvc.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
[Rename uvc_video_pump and uvc_queue_head as well]
[Rename forgotten uvc_queue_cancel instance in a comment]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The kbuild test bot generated the warning:
	drivers/usb/gadget/function/f_sourcesink.c:1498: warning: comparison is
	always false due to limited range of data type

This patch fixes it.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When configfs support is integrated the future uvc function
module must not take any parameters. Move parameters to
webcam.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Tested-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Simplify ioctl handling by using video_ioctl2.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

To handle class requests received on ep0, the driver needs to access the
length and direction of the request after the setup stage. It currently
stores them in a v4l2 event during the setup stage, and then copies them
from the event structure to the driver internal state structure when the
event is dequeued.

This two-steps approach isn't necessary. Simplify the driver by storing
the needed information in the driver internal state structure directly
during the setup stage.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The function cleaning up an initialized event
was called from the "event_del" handler, instead
of being used as the "destroy" callback. In case of
events group allocation this caused NULL pointer
dereference (as events are added and deleted
multiple times then). Fixed now.
Signed-off-by: NPawel Moll <mail@pawelmoll.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

This driver supports other SoCs, but they need boards/Soc depend code.
So, this patch adds device tree support for R-Car H2 and M2 initially.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Intensive tests with USB audio devices connected to a musb host port
have shown reproducible pops and clicks in both the playback and the
capture stream.

These are related to how the early_tx hrtimer is set up, and it turns
out they can be fixed by reducing the timer's slack value from 40 to
25 us. Also, when the callback is ran without taking action, it should
be rescheduled 20 us later instead of 50 us.
Reported-and-tested-by: NSven Neumann <neumann@teufel.de>
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.

[ balbi@ti.com : actually switch over to of_platform_depopulate() ]
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When we're debugging hard-to-reproduce and time-sensitive
use cases, printk() poses too much overhead. That's when
the kernel's tracing infrastructure comes into play.

This patch implements a few initial tracepoints for the
dwc3 driver. More traces can be added as necessary in order
to ease the task of debugging dwc3.
Reviewed-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional changes, just making sure we're dealing
with unsigned ints.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this new helper will return a pretty string for
DWC3 Gadget Events.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Those functions are only using within debugging
messages, grouping them into debug.h makes sense.

While at that, also add missing multiple inclusion
guard.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fixes not being able to init fence subsystem when multiple boards are
present.
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reverts commit 150b8be3.

The I2C core's per-adapter locks can't protect from IRQs, so the driver still
needs a spinlock to protect the register accesses.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is a following AB-BA dependency between cpu_hotplug.lock and
cpuidle_lock:

1) cpu_hotplug.lock -> cpuidle_lock
enable_nonboot_cpus()
 _cpu_up()
  cpu_hotplug_begin()
   LOCK(cpu_hotplug.lock)
 cpu_notify()
  ...
  acpi_processor_hotplug()
   cpuidle_pause_and_lock()
    LOCK(cpuidle_lock)

2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue
 ...
 acpi_processor_cst_has_changed()
  cpuidle_pause_and_lock()
   LOCK(cpuidle_lock)
  get_online_cpus()
   LOCK(cpu_hotplug.lock)

Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).

Spotted by lockdep.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _SUN device indentification object is not guaranteed to return
the same value every time it is executed, so we should not cache its
return value, but rather execute it every time as needed.  If it is
cached, an incorrect stale value may be used in some situations.

This issue was exposed by commit 202317a5 (ACPI / scan: Add
acpi_device objects for all device nodes in the namespace).  Fix it
by avoiding to cache the return value of _SUN.

Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[ rjw: Changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The current code just returns -EINVAL because mode can't be equal to
both 1 and 2.

Also this function is messy so I have cleaned it up:
1) Remove initializers like "int time = -1".  Initializing variables to
   garbage values turns off GCC's uninitialized variable warnings so it
   can lead to bugs.
2) Use kstrtoint() instead of sscanf().
3) Use SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO instead of magic numbers 1
   and 2.
4) Don't check for "mode == -1" because that can't happen.
5) Preserve the error code from toshiba_kbd_illum_status_set().
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

It should have been removed with commit d1b68485
("cpufreq / intel_pstate: Optimize intel_pstate_set_policy")
Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Many CPUs do not support complete set of RAPL domains, as a
result this detection failed message is very misleading and
can be annoying.

 [    5.082632] intel_rapl: RAPL domain core detection failed
 [    5.088370] intel_rapl: RAPL domain uncore detection failed

So lower the warning message to info and only print out the RAPL
domains that are supported.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

I've confirmed that monitoring the package power usage as well as setting power
limits appear to be working as expected. Supports the package and dram domains.

Tested aginst cpu:

Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
Signed-off-by: NJason Baron <jbaron@akamai.com>
Acked-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys
driven by toshiba_acpi are not functional.

Calling the ACPI object ENAB on resume makes them back alive.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This is a follow-up patch to commit 49458e83 ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This reverts commit 8b37e1be.

It's broken as it changes led_blink_set() in a way that it can now sleep
(while synchronously waiting for workqueue to be cancelled). That's a
problem, because it's possible that this function gets called from atomic
context (tpt_trig_timer() takes a readlock and thus disables preemption).

This has been brought up 3 weeks ago already [1] but no proper fix has
materialized, and I keep seeing the problem since 3.17-rc1.

[1] https://lkml.org/lkml/2014/8/16/128

 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
 5 locks held by wpa_supplicant/2335:
  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20
  #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
  #2:  (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
  #3:  (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
  #4:  (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]
 CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
  ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30
  ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f
  ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0
 Call Trace:
  [<ffffffff8159e97f>] dump_stack+0x4d/0x66
  [<ffffffff810739a5>] __might_sleep+0xe5/0x120
  [<ffffffff8106862f>] flush_work+0x5f/0x270
  [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
  [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
  [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
  [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
  [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
  [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
  [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
  [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
  [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
  [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
  [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
  [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
  [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
  [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
  [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
  [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
  [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
  [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
  [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
  [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
  [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
  [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
  [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
  [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
  [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
  [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
  [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
  [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0
  [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
  [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
  [<ffffffff814cfb29>] dev_ioctl+0x329/0x620
  [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
  [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
  [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
  [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56
  [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
  [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
  [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
 wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
 wlan0: authenticated
 wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
 wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
 wlan0: associated
 IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
 cfg80211: Calling CRDA for country: NA
 wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4

 =================================
 [ INFO: inconsistent lock state ]
 3.17.0-rc3 #1 Not tainted
 ---------------------------------
 inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
 swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
  ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270
 {SOFTIRQ-ON-W} state was registered at:
   [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30
   [<ffffffff81096c81>] lock_acquire+0x91/0x110
   [<ffffffff81068608>] flush_work+0x38/0x270
   [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
   [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
   [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
   [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
   [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
   [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
   [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
   [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
   [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
   [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
   [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
   [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
   [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
   [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
   [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
   [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
   [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
   [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
   [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
   [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
   [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
   [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
   [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
   [<ffffffff814cfb29>] dev_ioctl+0x329/0x620
   [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
   [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
   [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
   [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
 irq event stamp: 493416
 hardirqs last  enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100
 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160
 softirqs last  enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50
 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock((&(&led_cdev->blink_work)->work));
   <Interrupt>
     lock((&(&led_cdev->blink_work)->work));

  *** DEADLOCK ***

 2 locks held by swapper/0/0:
  #0:  (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180
  #1:  (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]

 stack backtrace:
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1
 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
  ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0
  ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001
  ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0
 Call Trace:
  <IRQ>  [<ffffffff8159e97f>] dump_stack+0x4d/0x66
  [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205
  [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140
  [<ffffffff810944d3>] mark_lock+0x223/0x2b0
  [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30
  [<ffffffff81096c81>] lock_acquire+0x91/0x110
  [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
  [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
  [<ffffffff81068608>] flush_work+0x38/0x270
  [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
  [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
  [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
  [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
  [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0
  [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
  [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
  [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
  [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
  [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
  [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180
  [<ffffffff810b4c50>] ? process_timeout+0x10/0x10
  [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
  [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0
  [<ffffffff81054805>] __do_softirq+0x115/0x2e0
  [<ffffffff81054c75>] irq_exit+0xa5/0xb0
  [<ffffffff810049b3>] do_IRQ+0x53/0xf0
  [<ffffffff815a74af>] common_interrupt+0x6f/0x6f
  <EOI>  [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180
  [<ffffffff8147b732>] cpuidle_enter+0x12/0x20
  [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360
  [<ffffffff8158fb51>] rest_init+0xc1/0xd0
  [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170
  [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a
  [<ffffffff81af399c>] ? set_init_arg+0x53/0x53
  [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c
  [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4

Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

The UAC2 function driver currently responds to all packets at all times
with wMaxPacketSize packets. That results in way too fast audio
playback as the function driver (which is in fact supposed to define
the audio stream pace) delivers as fast as it can.

Fix this by sizing each packet correctly with the following steps:

 a) Set the packet's size by dividing the nominal data rate by the
    playback endpoint's interval.

 b) If there is a residual value from the calculation in a), add
    it to a accumulator to keep track of it across packets.

 c) If the accumulator has gathered at least the number of bytes
    that are needed for one sample frame, increase the packet size.

This way, the packet size calculation will get rid of any kind of
imprecision that would otherwise occur with a simple division over
time.

Some of the variables that are needed while processing each packet
are pre-computed for performance reasons.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

With packet sizes other than 512, payloads in the packets may wrap
around the ALSA dma buffer partially, which leads to memory corruption
and audible clicks and pops in the audio stream at the moment, because
there is no boundary check before the memcpy().

In preparation to an implementation for smaller and dynamically sized
packets, we have to address such cases, and copy the payload in two
steps conditionally.

The 'src' and 'dst' approach doesn't work here anymore, as different
behavior is necessary in playback and capture cases. Thus, this patch
open-codes the routine now.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add a simple container_of() wrapper to get a struct f_uac2_opts from a
struct struct audio_dev. Use it in two places where it is currently
open-coded.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In afunc_bind() and afunc_set_alt(), &uac2->pdev.dev are used multiple
times. Adding a short-hand for them makes lines shorter so we can
remove some line wraps.

No functional change.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Restructure some code to make it easier to read.

While at it, return -ENOMEM instead of -EINVAL if
usb_ep_alloc_request() fails, and omit the logging in such cases
(the mm core will complain loud enough).
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Flatten the start_transfer function by reversing the if condition and
returning early out of the function if everything went fine.  It makes
the function look less complicated, at least to me, and easier to
understand.
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

commit f2267089(usb: gadget: composite: dequeue cdev->req before free it in
composite_dev_cleanup) fixed a bug: free the usb request(i.e. cdev->req) but
does not dequeue it beforehand. This fix is not proper enough because it
dequeues the request after free its data buffer, considering the hardware can
access the buffer's memory anytime before the request's complettion rountine
runs, and usb_ep_dequeue always call the complettion rountine before it returns,
so the best way is to dequeue the request before free its buffer.
Suggested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NLi Jun <b47624@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It's not being used any longer.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If NO_DMA=y:

drivers/built-in.o: In function `usbhsg_dma_map_ctrl':
mod_gadget.c:(.text+0x53b226): undefined reference to `usb_gadget_map_request'
mod_gadget.c:(.text+0x53b242): undefined reference to `usb_gadget_unmap_request'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

drivers/usb/phy/phy-samsung-usb[2,3] drivers got replaced by
drivers/phy/phy-samsung-usb[2,3] ones and the old common Samsung
USB PHY code is no longer used.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NVivek Gautam <gautam.vivek@samsung.com>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Cc: Kamil Debski <k.debski@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

drivers/usb/phy/phy-samsung-usb3 driver got replaced by
drivers/phy/phy-samsung-usb3 one and is no longer used.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NVivek Gautam <gautam.vivek@samsung.com>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Cc: Kamil Debski <k.debski@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>