- 17 Dec, 2012 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/soundTakashi Iwai authored
ASoC: More updates for v3.8 Nothing terribly exciting here, just small localised changes. As well as fixes there are a couple of Cirrus changes and one devm_ change which were in prior to the merge window but got missed from the original pull to Takashi.
-
- 15 Dec, 2012 9 commits
-
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Mark Brown authored
-
Bo Shen authored
Change the value of status to disabled to keep the consistent Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Misael Lopez Cruz authored
pop_wait is used to determine if a deferred playback close needs to be cancelled when the a PCM is open or if after the power-down delay expires it needs to run. pop_wait is associated with the CODEC DAI, so the CODEC DAI must be unique. This holds true for most CODECs, except for the dummy CODEC and its DAI. In DAI links with non-unique dummy CODECs (e.g. front-ends), pop_wait can be overwritten by another DAI link using also a dummy CODEC. Failure to cancel a deferred close can cause mute due to the DAPM STOP event sent in the deferred work. One scenario where pop_wait is overwritten and causing mute is below (where hw:0,0 and hw:0,1 are two front-ends with default pmdown_time = 5 secs): aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1 sleep 1 aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 & aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE Since CODECs may not be unique, pop_wait is moved to the PCM runtime structure. Creating separate dummy CODECs for each DAI link can also solve the problem, but at this point it's only pop_wait variable in the CODEC DAI that has negative effects by not being unique. Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Eldad Zack authored
As Joe Cooper <swelljoe@gmail.com> reported, "On most HP Envy laptops the snd-usb-audio module causes the system to become unresponsive and Gnome Shell 3 to crash.". See also: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-December/057729.html Add a quirk to ignore this device (for now) to solve the instability issue and allow other USB audio devices to be used. Reported-by: Joe Cooper <swelljoe@gmail.com> Tested-by: Isaac Smith <hunternet93@gmail.com> Signed-off-by: Eldad Zack <eldad@fogrefinery.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 14 Dec, 2012 1 commit
-
-
Takashi Iwai authored
We've seen the broken HDMI *video* output on some machines with GM965, and the debugging session pointed that the culprit is the disabled audio output pins. Toggling these pins dynamically on demand caused flickering of HDMI TV. This patch changes the behavior to keep the pin ON constantly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Dec, 2012 1 commit
-
-
Takashi Iwai authored
Fix the quirk entry for HP Pavilion dv7 in order to make the bass speaker working. Reported-and-tested-by: Tomas Pospisek <tpo2@sourcepole.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 12 Dec, 2012 6 commits
-
-
Takashi Iwai authored
The runtime_idle callback is the right place to check the suspend capability, but currently we do it wrongly in the runtime_suspend callback. This leads to a kernel error message like: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11 and the runtime PM core would even repeat the attempts. Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Cc: <stable@vger.kernel.org> [v3.7] Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Acer Aspire One 522 has the infamous digital mic unit that needs the phase inversion fixup for stereo. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The HD-audio driver artificially calls the suspend and the resume code path in the VGA switcheroo state changes. When a machine goes to suspend, it tries to suspend the device again, and it stalls at snd_power_wait(). This patch adds checks whether the devices were already in (forced) suspend in PM callbacks for avoiding the doubly suspend. Reported-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Denis Washington authored
The only required change is to extend the existing Xonar U1 mixer quirks to the U3, which seems to be controlled the same way. Signed-off-by: Denis Washington <denisw@online.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When the HD-audio controller is disabled (e.g. via vga switcheroo) but the driver is still accessing it, it spews floods of "spurious response" kernel messages. It's because CORB/RIRB WP reads 0xff, and the driver tries to fill up until this number. This patch changes the CORB/RIRB WP reads to word instead of byte, and add the check of the read value. If it's 0xffff, the controller is supposed to be disabled, so the further action will be skipped. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Mengdong Lin authored
Reducing the time on HDA link reset can help to reduce the driver loading time. So we replace msleep with usleep_range to get more accurate time control and change the value to a smaller one. And a 100ms timeout is set for both entering and exiting the link reset. Signed-off-by: Xingchao Wang <xingchao.wang@intel.com> Signed-off-by: Mengdong Lin <mengdong.lin@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 11 Dec, 2012 3 commits
-
-
Linus Torvalds authored
-
Florian Fainelli authored
The matrix-keymap module is currently lacking a proper module license, add one so we don't have this module tainting the entire kernel. This issue has been present since commit 1932811f ("Input: matrix-keymap - uninline and prepare for device tree support") Signed-off-by: Florian Fainelli <florian@openwrt.org> CC: stable@vger.kernel.org # v3.5+ Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Netlink socket dumping had several missing verifications and checks. In particular, address comparisons in the request byte code interpreter could access past the end of the address in the inet_request_sock. Also, address family and address prefix lengths were not validated properly at all. This means arbitrary applications can read past the end of certain kernel data structures. Fixes from Neal Cardwell. 2) ip_check_defrag() operates in contexts where we're in the process of, or about to, input the packet into the real protocols (specifically macvlan and AF_PACKET snooping). Unfortunately, it does a pskb_may_pull() which can modify the backing packet data which is not legal if the SKB is shared. It very much can be shared in this context. Deal with the possibility that the SKB is segmented by using skb_copy_bits(). Fix from Johannes Berg based upon a report by Eric Leblond. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: ipv4: ip_check_defrag must not modify skb before unsharing inet_diag: validate port comparison byte code to prevent unsafe reads inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run() inet_diag: validate byte code to prevent oops in inet_diag_bc_run() inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
-
- 10 Dec, 2012 12 commits
-
-
Linus Torvalds authored
This reverts commits a5091539 and d7c3b937. This is a revert of a revert of a revert. In addition, it reverts the even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the original commits in linux-next. It turns out that the original patch really was bogus, and that the original revert was the correct thing to do after all. We thought we had fixed the problem, and then reverted the revert, but the problem really is fundamental: waking up kswapd simply isn't the right thing to do, and direct reclaim sometimes simply _is_ the right thing to do. When certain allocations fail, we simply should try some direct reclaim, and if that fails, fail the allocation. That's the right thing to do for THP allocations, which can easily fail, and the GPU allocations want to do that too. So starting kswapd is sometimes simply wrong, and removing the flag that said "don't start kswapd" was a mistake. Let's hope we never revisit this mistake again - and certainly not this many times ;) Acked-by: Mel Gorman <mgorman@suse.de> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Johannes Berg authored
ip_check_defrag() might be called from af_packet within the RX path where shared SKBs are used, so it must not modify the input SKB before it has unshared it for defragmentation. Use skb_copy_bits() to get the IP header and only pull in everything later. The same is true for the other caller in macvlan as it is called from dev->rx_handler which can also get a shared SKB. Reported-by: Eric Leblond <eric@regit.org> Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linus Torvalds authored
This reverts commit 782fd304. We are going to reinstate the __GFP_NO_KSWAPD flag that has been removed, the removal reverted, and then removed again. Making this commit a pointless fixup for a problem that was caused by the removal of __GFP_NO_KSWAPD flag. The thing is, we really don't want to wake up kswapd for THP allocations (because they fail quite commonly under any kind of memory pressure, including when there is tons of memory free), and these patches were just trying to fix up the underlying bug: the original removal of __GFP_NO_KSWAPD in commit c6543459 ("mm: remove __GFP_NO_KSWAPD") was simply bogus. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Lydia Wang authored
Add support for new codec VT1808, which is similiar with VT1705CF. Signed-off-by: Lydia Wang <lydiawang@viatech.com.cn> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Lydia Wang authored
Add support for new codec VT1705CF. When power on/off Audio output converter of VT1705CF, the stream tag will be cleared. But driver caches the value. So when power on Audio output converter, the update_conv_power_state() will restore the saved stream tag of it. Signed-off-by: Lydia Wang <lydiawang@viatech.com.cn> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/soundTakashi Iwai authored
ASoC: Updates for v3.8 Some incremental updates, nothing too exciting. The biggest block here is the __dev annotation removal stuff from Bill, everything else is the usual driver-specific stuff - a combination of fixes and development. There will be at least more more set of fixes to come but I wanted to get these out ready for the merge window to make sure Bill's stuff makes it in.
-
Mark Brown authored
Don't wrap log messages over multiple lines, it makes them hard to grep for. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Paul Handrigan authored
Since VSP only has one power bit, only provide one DAPM widget. Signed-off-by: Paul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Paul Handrigan authored
Add power down delays between setting PDN and MCLKDIS for spk amp, spklo amp, and ear amp. Signed-off-by: Paul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Paul Handrigan authored
Signed-off-by: Paul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Lars-Peter Clausen authored
The 'addr' field of the sigma_action struct is stored as big endian in the firmware file. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org
-
Neal Cardwell authored
Add logic to verify that a port comparison byte code operation actually has the second inet_diag_bc_op from which we read the port for such operations. Previously the code blindly referenced op[1] without first checking whether a second inet_diag_bc_op struct could fit there. So a malicious user could make the kernel read 4 bytes beyond the end of the bytecode array by claiming to have a whole port comparison byte code (2 inet_diag_bc_op structs) when in fact the bytecode was not long enough to hold both. Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Dec, 2012 7 commits
-
-
Neal Cardwell authored
Add logic to check the address family of the user-supplied conditional and the address family of the connection entry. We now do not do prefix matching of addresses from different address families (AF_INET vs AF_INET6), except for the previously existing support for having an IPv4 prefix match an IPv4-mapped IPv6 address (which this commit maintains as-is). This change is needed for two reasons: (1) The addresses are different lengths, so comparing a 128-bit IPv6 prefix match condition to a 32-bit IPv4 connection address can cause us to unwittingly walk off the end of the IPv4 address and read garbage or oops. (2) The IPv4 and IPv6 address spaces are semantically distinct, so a simple bit-wise comparison of the prefixes is not meaningful, and would lead to bogus results (except for the IPv4-mapped IPv6 case, which this commit maintains). Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neal Cardwell authored
Add logic to validate INET_DIAG_BC_S_COND and INET_DIAG_BC_D_COND operations. Previously we did not validate the inet_diag_hostcond, address family, address length, and prefix length. So a malicious user could make the kernel read beyond the end of the bytecode array by claiming to have a whole inet_diag_hostcond when the bytecode was not long enough to contain a whole inet_diag_hostcond of the given address family. Or they could make the kernel read up to about 27 bytes beyond the end of a connection address by passing a prefix length that exceeded the length of addresses of the given family. Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neal Cardwell authored
Fix inet_diag to be aware of the fact that AF_INET6 TCP connections instantiated for IPv4 traffic and in the SYN-RECV state were actually created with inet_reqsk_alloc(), instead of inet6_reqsk_alloc(). This means that for such connections inet6_rsk(req) returns a pointer to a random spot in memory up to roughly 64KB beyond the end of the request_sock. With this bug, for a server using AF_INET6 TCP sockets and serving IPv4 traffic, an inet_diag user like `ss state SYN-RECV` would lead to inet_diag_fill_req() causing an oops or the export to user space of 16 bytes of kernel memory as a garbage IPv6 address, depending on where the garbage inet6_rsk(req) pointed. Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-