MSM_RQ_STATS: Clean the driver from mess, and unused function.
Staging: android: binder: Ratelimit binder debug messages

Ratelimit the binder debug messages, since they can get spammy and
flood the entire kernel log.

In some cases, enabling serial console with a spammy binder error can
cause a watchdog panic (and we don't have reports of this happening
with serial console disabled).

Signed-off-by: Chris Fries <cfries@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
nl80211: add scan width to bss and scan request structs

To allow scanning and working with 5 MHz and 10 MHz BSS, extend the
inform bss commands and add wrappers to take 5 and 10 MHz bss into
account.

Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Chet Lanctot <clanctot@codeaurora.org>
Signed-off-by: Amarnath Hullur Subramanyam <amarnath@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cfg80211: clarify BSS probe response vs. beacon data

There are a few possible cases of where BSS data came from:
 1) only a beacon has been received
 2) only a probe response has been received
 3) the driver didn't report what it received (this happens when
    using cfg80211_inform_bss[_width]())
 4) both probe response and beacon data has been received

Unfortunately, in the userspace API, a few things weren't there:
 a) there was no way to differentiate cases 1) and 4) above
    without comparing the data of the IEs
 b) the TSF was always from the last frame, instead of being
    exposed for beacon/probe response separately like IEs

Fix this by
   i) exporting a new flag attribute that indicates whether or
      not probe response data has been received - this addresses (a)
  ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
      if a beacon has been received
 iii) not exporting the beacon attributes in case (3) above as that
      would just lead userspace into thinking the data actually came
      from a beacon when that isn't clear

To implement this, track inside the IEs struct whether or not it
(definitely) came from a beacon.

Reported-by: William Seto
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Chet Lanctot <clanctot@codeaurora.org>
[amarnath@codeaurora.org: Only picked up the change in nl80211.h for the user
 space code to remain same. Other changes are not applicable for this version
 of the kernel]
Signed-off-by: Amarnath Hullur Subramanyam <amarnath@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: usbaudio: remove usbaudiosdev switch

- Remove usbaudiosdev switch to avoid reporting
  analog dock headset for USB headset

Signed-off-by: Divya Narayanan Poojary <dnaray@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: wcd9320: fix the no audio issue on triggering SSR

After the SSR is triggered there is possibility of the  mismatch
among  the cache register values and the actual hardware registers
values. Due to this some of the registers doesn't gets updated when
the enable sequence is triggered. This results incomplete path
getting enabled resulting in no audio.
Fix by updating the registers to the reset state and updating the
cache also. Also restart the mbhc for the proper headset detection

Signed-off-by: Aviral Gupta <aviralg@codeaurora.org>
Signed-off-by: Divya Narayanan Poojary <dnaray@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ASoC: msm: qdsp6v2: Add SLIMBUS 3 TX port as valid port

Add Slimbus 3 TX port to the list of valid ports.
Otherwise opening of this port will fail.

Signed-off-by: Damir Didjusto <damird@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect

Some USB-audio devices show weird sysfs warnings at disconnecting the
devices, e.g.
 usb 1-3: USB disconnect, device number 3
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180()
 sysfs group ffffffff8183df40 not found for kobject 'midiC1D0'
 Call Trace:
  [<ffffffff814a3e38>] ? dump_stack+0x49/0x71
  [<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0
  [<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50
  [<ffffffff813521e9>] ? device_del+0x39/0x180
  [<ffffffff81352339>] ? device_unregister+0x9/0x20
  [<ffffffff81352384>] ? device_destroy+0x34/0x40
  [<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd]
  [<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
  [<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd]
  [<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd]
  [<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd]
  [<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
  [<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
  [<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0
  [<ffffffff81355485>] ? device_release_driver+0x25/0x40
  [<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130
  [<ffffffff813522b9>] ? device_del+0x109/0x180
  [<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore]
  [<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore]
  [<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore]
  [<ffffffff810669f5>] ? sched_clock_local+0x15/0x80
  [<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0
  [<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0
  [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
  [<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
  [<ffffffff8105973e>] ? kthread+0xce/0xf0
  [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
  [<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0
  [<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
 ---[ end trace 40b1928d1136b91e ]---

This comes from the fact that usb-audio driver may receive the
disconnect callback multiple times, per each usb interface.  When a
device has both audio and midi interfaces, it gets called twice, and
currently the driver tries to release resources at the last call.
At this point, the first parent interface has been already deleted,
thus deleting a child of the first parent hits such a warning.

For fixing this problem, we need to call snd_card_disconnect() and
cancel pending operations at the very first disconnect while the
release of the whole objects waits until the last disconnect call.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931
Reported-and-tested-by: Tomas Gayoso <tgayoso@gmail.com>
Reported-and-tested-by: Chris J Arges <chris.j.arges@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: usbaudio: clean and update sound/usb/card.c from android 5.0

needed after commit https://github.com/neobuddy89/hammerhead/commit/c34ecbd3948939ce76df049233b1b78259696135