- 02 Aug, 2010 40 commits
-
-
Thomas Gleixner authored
commit 46732475 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by:
Esben Haabendal <eha@doredevelopment.dk> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev <linuxppc-dev@ozlabs.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex,Shi authored
commit 3c93717c upstream. Commit e7097159 ("sched: Optimize unused cgroup configuration") introduced an imbalanced scheduling bug. If we do not use CGROUP, function update_h_load won't update h_load. When the system has a large number of tasks far more than logical CPU number, the incorrect cfs_rq[cpu]->h_load value will cause load_balance() to pull too many tasks to the local CPU from the busiest CPU. So the busiest CPU keeps going in a round robin. That will hurt performance. The issue was found originally by a scientific calculation workload that developed by Yanmin. With that commit, the workload performance drops about 40%. CPU before after 00 : 2 : 7 01 : 1 : 7 02 : 11 : 6 03 : 12 : 7 04 : 6 : 6 05 : 11 : 7 06 : 10 : 6 07 : 12 : 7 08 : 11 : 6 09 : 12 : 6 10 : 1 : 6 11 : 1 : 6 12 : 6 : 6 13 : 2 : 6 14 : 2 : 6 15 : 1 : 6 Reviewed-by:
Yanmin zhang <yanmin.zhang@intel.com> Signed-off-by:
Alex Shi <alex.shi@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1276754893.9452.5442.camel@debian> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Will Deacon authored
commit 0d98bb26 upstream. GCC 4.4.1 on ARM has been observed to replace the while loop in sched_avg_update with a call to uldivmod, resulting in the following build failure at link-time: kernel/built-in.o: In function `sched_avg_update': kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' make: *** [.tmp_vmlinux1] Error 1 This patch introduces a fake data hazard to the loop body to prevent the compiler optimising the loop away. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Darrick J. Wong authored
commit d596043d upstream. The x3950 family can have as many as 256 PCI buses in a single system, so change the limits to the maximum. Since there can only be 256 PCI buses in one domain, we no longer need the BUG_ON check. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Darrick J. Wong authored
commit 499a00e9 upstream. Newer systems (x3950M2) can have 48 PHBs per chassis and 8 chassis, so bump the limits up and provide an explanation of the requirements for each class. Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com> LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com> [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ] Signed-off-by:
-
Andi Kleen authored
commit 12448293 upstream. This fixes the -Os breaks with gcc 4.5 bug. rdtsc_barrier needs to be force inlined, otherwise user space will jump into kernel space and kill init. This also addresses http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129 I believe. Signed-off-by:
Andi Kleen <ak@linux.intel.com> LKML-Reference: <20100618210859.GA10913@basil.fritz.box> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Frederic Weisbecker authored
commit 97aa1052 upstream. Initialize the callchain radix tree root correctly. When we walk through the parents, we must stop after the root, but since it wasn't well initialized, its parent pointer was random. Also the number of hits was random because uninitialized, hence it was part of the callchain while the root doesn't contain anything. This fixes segfaults and percentages followed by empty callchains while running: perf report -g flat Reported-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Ben Hutchings authored
commit 6fd02489 upstream. The current initialisation code probes 'unsupported' AGP devices simply by calling its own probe function. It does not lock these devices or even check whether another driver is already bound to them. We must use the device core to manage this. So if the specific device id table didn't match anything and agp_try_unsupported=1, switch the device id table and call driver_attach() again. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Julia Lawall authored
commit 8a52da63 upstream. The debugging code using the freed structure is moved before the kfree. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @free@ expression E; position p; @@ kfree@p(E) @@ expression free.E, subE<=free.E, E1; position free.p; @@ kfree@p(E) ... ( subE = E1 | * E ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Eric Dumazet authored
commit 499031ac upstream. We should release dst if dst->error is set. Bug introduced in 2.6.14 by commit e104411b ([XFRM]: Always release dst_entry on error in xfrm_lookup) Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Sven Wegener authored
commit aea9d711 upstream. The code that hashes and unhashes connections from the connection table is missing locking of the connection being modified, which opens up a race condition and results in memory corruption when this race condition is hit. Here is what happens in pretty verbose form: CPU 0 CPU 1 ------------ ------------ An active connection is terminated and we schedule ip_vs_conn_expire() on this CPU to expire this connection. IRQ assignment is changed to this CPU, but the expire timer stays scheduled on the other CPU. New connection from same ip:port comes in right before the timer expires, we find the inactive connection in our connection table and get a reference to it. We proper lock the connection in tcp_state_transition() and read the connection flags in set_tcp_state(). ip_vs_conn_expire() gets called, we unhash the connection from our connection table and remove the hashed flag in ip_vs_conn_unhash(), without proper locking! While still holding proper locks we write the connection flags in set_tcp_state() and this sets the hashed flag again. ip_vs_conn_expire() fails to expire the connection, because the other CPU has incremented the reference count. We try to re-insert the connection into our connection table, but this fails in ip_vs_conn_hash(), because the hashed flag has been set by the other CPU. We re-schedule execution of ip_vs_conn_expire(). Now this connection has the hashed flag set, but isn't actually hashed in our connection table and has a dangling list_head. We drop the reference we held on the connection and schedule the expire timer for timeouting the connection on this CPU. Further packets won't be able to find this connection in our connection table. ip_vs_conn_expire() gets called again, we think it's already hashed, but the list_head is dangling and while removing the connection from our connection table we write to the memory location where this list_head points to. The result will probably be a kernel oops at some other point in time. This race condition is pretty subtle, but it can be triggered remotely. It needs the IRQ assignment change or another circumstance where packets coming from the same ip:port for the same service are being processed on different CPUs. And it involves hitting the exact time at which ip_vs_conn_expire() gets called. It can be avoided by making sure that all packets from one connection are always processed on the same CPU and can be made harder to exploit by changing the connection timeouts to some custom values. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Rajiv Andrade authored
commit 59f6fbe4 upstream. Fix subsequent suspends by issuing tpm_continue_selftest during resume. Otherwise, the tpm chip seems to be not fully initialized and will reject the save state command during suspend, thus preventing the whole system to suspend. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16256Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: James Morris <jmorris@namei.org> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: David Safford <safford@watson.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Alex Deucher authored
commit 15cb02c0 upstream. Add delay after turning off the LVDS encoder. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16389Tested-by:
Jan Kreuzer <kontrollator@gmx.de> Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit e153b70b upstream. Connector is actually DVI rather than HDMI. Reported-by:
trapDoor <trapdoor6@gmail.com> Signed-off-by:
-
Roland Scheidegger authored
commit 688acaa2 upstream. Code did not handle projected 2d and depth coordinates, meaning potentially set 3d or cube special handling might stick. (Not sure what depth coord actually does, but I guess handling it like a normal coordinate is the right thing to do.) Might be related to https://bugs.freedesktop.org/show_bug.cgi?id=26428 Signed-off-by: sroland@vmware.com Signed-off-by:
-
Adam Jackson authored
commit 6ba770dc upstream. Fixes an Ironlake laptop with a 68.940MHz 1280x800 panel and 120MHz SSC reference clock. More generally, the 0.488% tolerance used before is just too tight to reliably find a PLL setting. I extracted the search algorithm and modified it to find the dot clocks with maximum error over the valid range for the given output type: http://people.freedesktop.org/~ajax/intel_g4x_find_best_pll.c This gave: Worst dotclock for Ironlake DAC refclk is 350000kHz (error 0.00571) Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524) Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488) Worst dotclock for Ironlake SL-LVDS SSC refclk is 84374kHz (error 0.00529) Worst dotclock for Ironlake DL-LVDS SSC refclk is 183035kHz (error 0.00488) Worst dotclock for G4X SDVO refclk is 267600kHz (error 0.00448) Worst dotclock for G4X HDMI refclk is 334400kHz (error 0.00478) Worst dotclock for G4X SL-LVDS refclk is 95571kHz (error 0.00449) Worst dotclock for G4X DL-LVDS refclk is 224000kHz (error 0.00510) Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Dave Airlie authored
commit 94400120 upstream. A lot of 945GMs have had stability issues for a long time, this manifested as X hangs, blitter engine hangs, and lots of crashes. one such report is at: https://bugs.freedesktop.org/show_bug.cgi?id=20560 along with numerous distro bugzillas. This only took a week of digging and hair ripping to figure out. Tracked down and tested on a 945GM Lenovo T60, previously running x11perf -copypixwin500 or x11perf -copywinpix500 repeatedly would cause the GPU to wedge within 4 or 5 tries, with random busy bits set. After this patch no hangs were observed. Signed-off-by:
-
Keith Packard authored
commit 45503ded upstream. The i915 memory arbiter has a register full of configuration bits which are currently not defined in the driver header file. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Daniel J Blueman authored
commit f953c935 upstream. While investigating Intel i5 Arrandale GPU lockups with -rc4, I noticed a lock imbalance. Signed-off-by:
Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by:
-
Jason Baron authored
commit b82bab4b upstream. The command echo "file ec.c +p" >/sys/kernel/debug/dynamic_debug/control causes an oops. Move the call to ddebug_remove_module() down into free_module(). In this way it should be called from all error paths. Currently, we are missing the remove if the module init routine fails. Signed-off-by:
Jason Baron <jbaron@redhat.com> Reported-by:
Thomas Renninger <trenn@suse.de> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Joerg Albert authored
commit 50900f16 upstream. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Dan Rosenberg authored
commit 2ebc3464 upstream. 1. The BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE ioctls should check whether the donor file is append-only before writing to it. 2. The BTRFS_IOC_CLONE_RANGE ioctl appears to have an integer overflow that allows a user to specify an out-of-bounds range to copy from the source file (if off + len wraps around). I haven't been able to successfully exploit this, but I'd imagine that a clever attacker could use this to read things he shouldn't. Even if it's not exploitable, it couldn't hurt to be safe. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Javier Cardona authored
commit 1cb561f8 upstream. This fixes the problem introduced in commit 84040805 which broke mesh peer link establishment. changes: v2 Added missing break (Johannes) v3 Broke original patch into two (Johannes) Signed-off-by:
Javier Cardona <javier@cozybit.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Stanislaw Gruszka authored
commit f0b058b6 upstream. Use old supported rates, if AP do not provide supported rates information element in a new managment frame. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
John W. Linville authored
commit a69b03e9 upstream. Avoids this: WARNING: at net/mac80211/scan.c:312 ieee80211_scan_completed+0x5f/0x1f1 [mac80211]() Hardware name: Latitude E5400 Modules linked in: aes_x86_64 aes_generic fuse ipt_MASQUERADE iptable_nat nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel iwlagn snd_hda_codec snd_hwdep snd_seq snd_seq_device iwlcore snd_pcm dell_wmi sdhci_pci sdhci iTCO_wdt tg3 dell_laptop mmc_core i2c_i801 wmi mac80211 snd_timer iTCO_vendor_support btusb joydev dcdbas cfg80211 bluetooth snd soundcore microcode rfkill snd_page_alloc firewire_ohci firewire_core crc_itu_t yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Pid: 979, comm: iwlagn Tainted: G W 2.6.33.3-85.fc13.x86_64 #1 Call Trace: [<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f [<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11 [<ffffffffa01bb7d9>] ieee80211_scan_completed+0x5f/0x1f1 [mac80211] [<ffffffffa02a23f0>] iwl_bg_scan_completed+0xbb/0x17a [iwlcore] [<ffffffff81060d3d>] worker_thread+0x1a4/0x232 [<ffffffffa02a2335>] ? iwl_bg_scan_completed+0x0/0x17a [iwlcore] [<ffffffff81064817>] ? autoremove_wake_function+0x0/0x34 [<ffffffff81060b99>] ? worker_thread+0x0/0x232 [<ffffffff810643c7>] kthread+0x7a/0x82 [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10 [<ffffffff8106434d>] ? kthread+0x0/0x82 [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10 Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=590436Signed-off-by:
Mihai Harpau <mishu@piatafinanciara.ro> Acked-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Dave Airlie authored
commit b26c9497 upstream. When I added the flags I must have been using a 25 line terminal and missed the following flags. The collided with flag has one user in staging despite being in-tree for 5 years. I'm happy to push this via my drm tree unless someone really wants to do it. Signed-off-by:
-
Rajiv Andrade authored
commit 02a077c5 upstream. This patch adds a missing element of the ReadPubEK command output, that prevents future overflow of this buffer when copying the TPM output result into it. Prevents a kernel panic in case the user tries to read the pubek from sysfs. Signed-off-by:
-
Tim Gardner authored
commit d6a574ff upstream. Use an irq spinlock to hold off the IRQ handler until enough early card init is complete such that the handler can run without faulting. Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Vivek Natarajan authored
commit 3a374952 upstream. If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate with WEP or TKIP, eventhough the received frame may be a CRC failed corrupted frame. If this bit is set, H/W obeys key type in keycache. If it is not set and if the key type in keycache is neither open nor AES, H/W forces key type to be open. But bit 29 should be set to 1 for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP. Reported-by:
Johan Hovold <johan.hovold@lundinova.se> Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
Ranga Rao Ravuri <ranga.ravuri@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit 14acdde6 upstream. The newer single chip hardware family of chipsets have not been experiencing issues with power saving set by default with recent fixes merged (even into stable). The remaining issues are only reported with AR5416 and since enabling PS by default can increase power savings considerably best to take advantage of that feature as this has been tested properly. For more details on this issue see the bug report: http://bugzilla.kernel.org/show_bug.cgi?id=14267 We leave AR5416 with PS disabled by default, that seems to require some more work. Cc: Peter Stuge <peter@stuge.se> Cc: Justin P. Mattock <justinmattock@gmail.com> Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit 9637e516 upstream. Jumbo frames are not supported, and if they are seen it is likely a bogus frame so just silently discard them instead of warning on them all time. Also, instead of dropping them immediately though move the check *after* we check for all sort of frame errors. This should enable us to discard these frames if the hardware picks other bogus items first. Lets see if we still get those jumbo counters increasing still with this. Jumbo frames would happen if we tell hardware we can support a small 802.11 chunks of DMA'd frame, hardware would split RX'd frames into parts and we'd have to reconstruct them in software. This is done with USB due to the bulk size but with ath5k we already provide a good limit to hardware and this should not be happening. This is reported quite often and if it fills the logs then this needs to be addressed and to avoid spurious reports. Signed-off-by:
-
Trond Myklebust authored
commit b76ce561 upstream. If the attempt to read the calldir fails, then instead of storing the read bytes, we currently discard them. This leads to a garbage final result when upon re-entry to the same routine, we read the remaining bytes. Fixes the regression in bugzilla number 16213. Please see https://bugzilla.kernel.org/show_bug.cgi?id=16213Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 0be8189f upstream. Currently, we do not display the minor version mount parameter in the /proc mount info. Signed-off-by:
-
Trond Myklebust authored
commit d3f6baaa upstream. Apparently, we have never been able to set the atime correctly from the NFSv4 client. Reported-by:
小倉一夫 <ka-ogura@bd6.so-net.ne.jp> Signed-off-by:
-
Mikael Pettersson authored
commit f8324e20 upstream. The kernel's math-emu code contains a macro _FP_FROM_INT() which is used to convert an integer to a raw normalized floating-point value. It does this basically in three steps: 1. Compute the exponent from the number of leading zero bits. 2. Downshift large fractions to put the MSB in the right position for normalized fractions. 3. Upshift small fractions to put the MSB in the right position. There is an boundary error in step 2, causing a fraction with its MSB exactly one bit above the normalized MSB position to not be downshifted. This results in a non-normalized raw float, which when packed becomes a massively inaccurate representation for that input. The impact of this depends on a number of arch-specific factors, but it is known to have broken emulation of FXTOD instructions on UltraSPARC III, which was originally reported as GCC bug 44631 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631>. Any arch which uses math-emu to emulate conversions from integers to same-size floats may be affected. The fix is simple: the exponent comparison used to determine if the fraction should be downshifted must be "<=" not "<". I'm sending a kernel module to test this as a reply to this message. There are also SPARC user-space test cases in the GCC bug entry. Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rob Landley authored
commit 7469a9ac upstream. Signed-off-by:
Rob Landley <rob@landley.net> Signed-off-by:
-
Alexander Duyck authored
commit 22896639 upstream. This patch allows us to treat the alternate mac address as though it is the physical address on the adapter. This is accomplished by letting the alt_mac_address function to only fail on an NVM error. If no errors occur and the alternate mac address is not present then RAR0 is read as the default mac address. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Brandon Philips authored
commit 38000a94 upstream. sky2_phy_reinit is called by the ethtool helpers sky2_set_settings, sky2_nway_reset and sky2_set_pauseparam when netif_running. However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to stop working: $ ethtool -r eth0 $ ethtool -A eth0 autoneg off Fix this issue by enabling Rx/Tx after running sky2_phy_init in sky2_phy_reinit. Signed-off-by:
Brandon Philips <bphilips@suse.de> Tested-by:
Mike McCormack <mikem@ring3k.org> Signed-off-by:
-
Florian Fainelli authored
commit ed770f01 upstream. If the call to phy_connect fails, we will return directly instead of freeing the previously allocated struct net_device. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Luke Yelavich authored
commit 3bfea98f upstream. BugLink: https://bugs.launchpad.net/bugs/463178 Set Macbook 5,2 (106b:4a00) hardware to use ALC885_MB5 Signed-off-by:
Luke Yelavich <luke.yelavich@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
