- 06 Feb, 2014 25 commits
-
-
Larry Finger authored
commit f87f960b upstream. Reported-by:
Jan Prinsloo <janroot@gmail.com> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
commit feffe09f upstream. According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 Without this patcheset, imx28 works unstable at high AHB bus loading. If the bus loading is not high, the imx28 usb can work well at the most of time. There is a IC errata for this problem, usually, we consider IC errata is a problem not a new feature, and this workaround is needed for that, so we need to add them to stable tree 3.11+. Cc: robert.hodaszi@digi.com Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Tested-by:
-
Alan Stern authored
commit 543d7784 upstream. There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [<c16d5fb0>] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d5fc4>] recursively_mark_NOTATTACHED+0x34/0x60 [<c16d6082>] usb_set_device_state+0x92/0x120 [<c16d862b>] usb_disconnect+0x2b/0x1a0 [<c16dd4c0>] usb_remove_hcd+0xb0/0x160 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c1704efc>] ehci_mid_remove+0x1c/0x30 [<c1704f26>] ehci_mid_stop_host+0x16/0x30 [<c16f7698>] penwell_otg_work+0xd28/0x3520 [<c19c945b>] ? __schedule+0x39b/0x7f0 [<c19cdb9d>] ? sub_preempt_count+0x3d/0x50 [<c125e97d>] process_one_work+0x11d/0x3d0 [<c19c7f4d>] ? mutex_unlock+0xd/0x10 [<c125e0e5>] ? manage_workers.isra.24+0x1b5/0x270 [<c125f009>] worker_thread+0xf9/0x320 [<c19ca846>] ? _raw_spin_unlock_irqrestore+0x26/0x50 [<c125ef10>] ? rescuer_thread+0x2b0/0x2b0 [<c1264ac4>] kthread+0x94/0xa0 [<c19d0f77>] ret_from_kernel_thread+0x1b/0x28 [<c1264a30>] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by:
"Du, Changbin" <changbinx.du@intel.com> Tested-by:
-
Jack Pham authored
commit 9005355a upstream. If CONFIG_PCI is enabled, make sure xhci_cleanup_msix() doesn't try to free a bogus PCI IRQ or dereference an invalid pci_dev when the xHCI device is actually a platform_device. This patch should be backported to kernels as old as 3.9, that contain the commit 52fb6125 "xhci-plat: Don't enable legacy PCI interrupts." Signed-off-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Mikhail Zolotaryov authored
commit 0e16114f upstream. The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by:
Mikhail Zolotaryov <lebon@lebon.org.ua> Signed-off-by:
-
Colin Leitner authored
commit c1f15196 upstream. Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f ("USB: ftdi_sio: fixed handling of unsupported CSIZE setting") enforced this limitation and reported it back to userspace. However, certain types of smartcard readers depend on specific driver behaviour that requests 0 data bits (not 5) to change into a different operating mode if CS5 has been set. This patch reenables this behaviour for all FTDI devices. Tagged to be added to stable, because it affects a lot of users of embedded systems which rely on these readers to work properly. Reported-by:
Heinrich Siebmanns <H.Siebmanns@t-online.de> Tested-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 440ebade upstream. Fix ring-indicator (RI) status-bit definition, which was defined as CTS, effectively preventing RI-changes from being detected while reporting false RI status. This bug predates git. Signed-off-by:
-
Rahul Bedarkar authored
commit 7d5c1b9c upstream. Add support for iBall 3.5G connect usb modem. $lsusb Bus 002 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY $usb-devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9605 Rev=00.00 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber=1234567890ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Suggested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
张君 authored
commit 4d90b819 upstream. Signed-off-by:
Jun zhang <zhang.jun92@zte.com.cn> Signed-off-by:
-
Johan Hovold authored
commit 623c8263 upstream. Some PL2303 devices are known to lose bytes if you change serial settings even to the same values as before. Avoid this by comparing the encoded settings with the previsouly used ones before configuring the device. The common case was fixed by commit bf5e5834 ("pl2303: Fix mode switching regression"), but this problem was still possible to trigger, for instance, by using the TCSETS2-interface to repeatedly request 115201 baud, which gets mapped to 115200 and thus always triggers a settings update. Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Heikki Krogerus authored
commit 13518673 upstream. The reset_gpio member of the usb_phy_gen_xceiv_platform_data structure needs the have negative value or phy-generic's probe will fail unless DT is used. 0 is a valid gpio number. This fixes an issue where phy-generic fails to probe with message: "usb_phy_gen_xceiv.0: Error requesting RESET GPIO 0". Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Bjørn Mork authored
commit f563926f upstream. Do not decrement resp_count if it's already 0. We set resp_count to 0 when the device is closed. The next open and read will try to clear the WDM_READ flag if there was leftover data in the read buffer. This fix is necessary to prevent resubmitting the read URB in a tight loop because resp_count becomes negative. The bug can easily be triggered from userspace by not reading all data in the read buffer, and then closing and reopening the chardev. Fixes: 8dd5cd53 ("usb: cdc-wdm: avoid hanging on zero length reads") Signed-off-by:
-
Bjørn Mork authored
commit 8dd5cd53 upstream. commit 73e06865 ("USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications") implemented queued response handling. This added a new requirement: The read urb must be resubmitted every time we clear the WDM_READ flag if the response counter indicates that the device is waiting for a read. Fix by factoring out the code handling the WMD_READ clearing and possible urb submission, calling it everywhere we clear the flag. Without this fix, the driver ends up in a state where the read urb is inactive, but the response counter is positive after a zero length read. This prevents the read urb from ever being submitted again and the driver appears to be hanging. Fixes: 73e06865 ("USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications") Cc: Greg Suarez <gsuarez@smithmicro.com> Signed-off-by:
-
Peter Chen authored
commit 2fc5a7da upstream. We have met a bug that the high bandwidth ISO-TX transfer has failed at the last packet if it is less than 1024, the TD status shows it is "Transaction Error". The root cause of this problem is: the mult value at qh is not correct for current TD's transfer length. We use TD list to queue un-transfer TDs, and change mult for new adding TDs. If new adding TDs transfer length less than 1024, but the queued un-transfer TDs transfer length is larger than 1024, the transfer error will occur, and vice versa. Usually, this problem occurs at the last packet, and the first packet for new frame. We fixed this problem by setting Mult at QH as the largest value (3), and set MultO (Multiplier Override) at TD according to every transfer length. It can cover both hardware version less than 2.3 (the real mult is MultO if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)). Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior unchanged. For stable tree: 3.11+. Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Reported-by:
Matthieu Vanin <b47495@freescale.com> Tested-by:
-
Peter Chen authored
commit 5332ff1f upstream. For otgsc, both enable bits and status bits are in it. So we need to make sure the status bits are not be cleared when write enable bits. It can fix one bug that we plug in/out Micro AB cable fast, and sometimes, the IDIS will be cleared wrongly when handle last ID interrupt (ID 0->1), so the current interrupt will not occur. For stable tree: 3.12+ Signed-off-by:
-
Peter Chen authored
commit 1071055e upstream. Due to imx28 needs ARM swp instruction for writing, we set CI_HDRC_IMX28_WRITE_FIX for imx28. This patch is needed for stable tree 3.11+ Cc: robert.hodaszi@digi.com Signed-off-by:
-
Peter Chen authored
commit ed8f8318 upstream. According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB register error issue", All USB register write operations must use the ARM SWP instruction. So, we implement special hw_write and hw_test_and_clear for imx28. Discussion for it at below: http://marc.info/?l=linux-usb&m=137996395529294&w=2 This patch is needed for stable tree 3.11+. Cc: robert.hodaszi@digi.com Signed-off-by:
-
Paolo Bonzini authored
commit 77f01bdf upstream. When Hyper-V hypervisor leaves are present, KVM must relocate its own leaves at 0x40000100, because Windows does not look for Hyper-V leaves at indices other than 0x40000000. In this case, the KVM features are at 0x40000101, but the old code would always look at 0x40000001. Fix by using kvm_cpuid_base(). This also requires making the function non-inline, since kvm_cpuid_base() is static. Fixes: 1085ba7f Cc: mtosatti@redhat.com Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
commit 1c300a40 upstream. It is unnecessary to go through hypervisor_cpuid_base every time a leaf is found (which will be every time a feature is requested after the next patch). Fixes: 1085ba7f Cc: mtosatti@redhat.com Signed-off-by:
-
Marcelo Tosatti authored
commit 9ed96e87 upstream. Limit PIT timer frequency similarly to the limit applied by LAPIC timer. Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Dave Young authored
commit a7f84f03 upstream. Current code check boot service region with kernel text region by: start+size >= __pa_symbol(_text) The end of the above region should be start + size - 1 instead. I see this problem in ovmf + Fedora 19 grub boot: text start: 1000000 md start: 800000 md size: 800000 Signed-off-by:
Dave Young <dyoung@redhat.com> Acked-by:
Borislav Petkov <bp@suse.de> Acked-by:
Toshi Kani <toshi.kani@hp.com> Tested-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Ben Hutchings authored
commit b7ef4a6d upstream. We can't include <asm/pci_x86.h> if this isn't x86, and we only need it if CONFIG_PCI_MMCONFIG is enabled. Fixes: 8deb3eb1 ('xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved for MCFG areas.') Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
-
PaX Team authored
commit 2def2ef2 upstream. The x32 case for the recvmsg() timout handling is broken: asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg, unsigned int vlen, unsigned int flags, struct compat_timespec __user *timeout) { int datagrams; struct timespec ktspec; if (flags & MSG_CMSG_COMPAT) return -EINVAL; if (COMPAT_USE_64BIT_TIME) return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen, flags | MSG_CMSG_COMPAT, (struct timespec *) timeout); ... The timeout pointer parameter is provided by userland (hence the __user annotation) but for x32 syscalls it's simply cast to a kernel pointer and is passed to __sys_recvmmsg which will eventually directly dereference it for both reading and writing. Other callers to __sys_recvmmsg properly copy from userland to the kernel first. The bug was introduced by commit ee4fa23c ("compat: Use COMPAT_USE_64BIT_TIME in net/compat.c") and should affect all kernels since 3.4 (and perhaps vendor kernels if they backported x32 support along with this code). Note that CONFIG_X86_X32_ABI gets enabled at build time and only if CONFIG_X86_X32 is enabled and ld can build x32 executables. Other uses of COMPAT_USE_64BIT_TIME seem fine. This addresses CVE-2014-0038. Signed-off-by:
PaX Team <pageexec@freemail.hu> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Rientjes authored
commit 8790c71a upstream. As a result of commit 5606e387 ("mm: numa: Migrate on reference policy"), /proc/<pid>/numa_maps prints the mempolicy for any <pid> as "prefer:N" for the local node, N, of the process reading the file. This should only be printed when the mempolicy of <pid> is MPOL_PREFERRED for node N. If the process is actually only using the default mempolicy for local node allocation, make sure "default" is printed as expected. Signed-off-by:
David Rientjes <rientjes@google.com> Reported-by:
Robert Lippert <rlippert@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Acked-by:
Mel Gorman <mgorman@suse.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Aristeu Rozanski authored
commit 90ed4988 upstream. In case the device 0, function 1 is not found using pci_get_device(), pci_scan_single_device() will be used but, differently than pci_get_device(), it allocates a pci_dev but doesn't does bump the usage count on the pci_dev and after few module removals and loads the pci_dev will be freed. Signed-off-by:
Aristeu Rozanski <aris@redhat.com> Reviewed-by:
mark gross <mark.gross@intel.com> Link: http://lkml.kernel.org/r/20131205153755.GL4545@redhat.comSigned-off-by:
-
- 29 Jan, 2014 11 commits
-
-
Greg Kroah-Hartman authored
-
NeilBrown authored
commit 7da9d450 upstream. As release_stripe and __release_stripe decrement ->count and then manipulate ->lru both under ->device_lock, it is important that get_active_stripe() increments ->count and clears ->lru also under ->device_lock. However we currently list_del_init ->lru under the lock, but increment the ->count outside the lock. This can lead to races and list corruption. So move the atomic_inc(&sh->count) up inside the ->device_lock protected region. Note that we still increment ->count without device lock in the case where get_free_stripe() was called, and in fact don't take ->device_lock at all in that path. This is safe because if the stripe_head can be found by get_free_stripe, then the hash lock assures us the no-one else could possibly be calling release_stripe() at the same time. Fixes: 566c09c5Reported-and-tested-by:
Ian Kumlien <ian.kumlien@gmail.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit 9f97e4b1 upstream. Before a write starts we set a bit in the write-intent bitmap. When the write completes we clear that bit if the write was successful to all devices. However if the write wasn't fully successful we should not clear the bit. If the faulty drive is subsequently re-added, the fact that the bit is still set ensure that we will re-write the data that is missing. This logic is mediated by the STRIPE_DEGRADED flag - we only clear the bitmap bit when this flag is not set. Currently we correctly set the flag if a write starts when some devices are failed or missing. But we do *not* set the flag if some device failed during the write attempt. This is wrong and can result in clearing the bit inappropriately. So: set the flag when a write fails. This bug has been present since bitmaps were introduces, so the fix is suitable for any -stable kernel. Reported-by:
Ethan Wilson <ethan.wilson@shiftmail.org> Signed-off-by:
-
David Henningsson authored
commit da4a7a39 upstream. This should help us avoid the following mutex deadlock: [] mutex_lock+0x2a/0x50 [] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi] [] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi] [] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec] [] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec] [] codec_exec_verb+0x5f/0x290 [snd_hda_codec] [] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec] [] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi] [] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi] [] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi] [] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi] Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Fixes: cbbaa603 ('ALSA: hda - Fix possible races in HDMI driver') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Guenter Roeck authored
commit 4288d9b8 upstream. Commit 338de0ca (extcon: gpio: Use gpio driver/chip debounce if supported) introduced a call to gpio_set_debounce() before actually requesting the respective gpio pin from the gpio subsystem. The gpio subsystem expects that a gpio pin was requested before modifying its state. Not doing so results in a warning from gpiolib, and the gpio pin is auto-requested. This in turn causes the subsequent devm_gpio_request_one() to fail. So devm_gpio_request_one() must be called prior to calling gpio_set_debounce(). Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Jon Medhurst authored
commit fe433907 upstream. When the pl011 is being used for a console, pl011_console_write forces the control register (CR) to enable the UART for transmission and then restores this to the original value afterwards. It does this while holding the port lock. Unfortunately, when the uart is started or shutdown - say in response to userland using the serial device for a terminal - then this updates the control register without any locking. This means we can have pl011_console_write Save CR pl011_startup Initialise CR, e.g. enable receive pl011_console_write Restore old CR with receive not enabled this result is a serial port which doesn't respond to any input. A similar race in reverse could happen when the device is shutdown. We can fix these problems by taking the port lock when updating CR. Signed-off-by:
Jon Medhurst <tixy@linaro.org> Signed-off-by:
-
Geert Uytterhoeven authored
commit f92f455f upstream. {,set}page_address() are macros if WANT_PAGE_VIRTUAL. If !WANT_PAGE_VIRTUAL, they're plain C functions. If someone calls them with a void *, this pointer is auto-converted to struct page * if !WANT_PAGE_VIRTUAL, but causes a build failure on architectures using WANT_PAGE_VIRTUAL (arc, m68k and sparc64): drivers/md/bcache/bset.c: In function `__btree_sort': drivers/md/bcache/bset.c:1190: warning: dereferencing `void *' pointer drivers/md/bcache/bset.c:1190: error: request for member `virtual' in something not a structure or union Convert them to static inline functions to fix this. There are already plenty of users of struct page members inside <linux/mm.h>, so there's no reason to keep them as macros. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
-
H Hartley Sweeten authored
commit 48108fe3 upstream. The dev->irq passed to request_irq() will always be 0 when the auto_attach function is called. The pcidev->irq should be used instead to get the correct irq number. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
H Hartley Sweeten authored
commit 90daf69a upstream. The SDF_CMD_READ should be one of the s->subdev_flags not part of the s->type. Signed-off-by:
-
Bernd Porr authored
commit e56b1401 upstream. If the channel list is not set in userspace we get an error at PTR_ERR(async->cmd.chanlist). However, do_become_nonbusy(dev, s) cleans up this pointer which causes a kernel ooops. Setting the channel list in async to NULL and checking this in do_become_nonbusy prevents the oops. [Ian Abbott] Also do the same for the chanlist allocated in do_cmdtest_ioctl(). Signed-off-by:
Bernd Porr <mail@berndporr.me.uk> Signed-off-by:
-
Bob Peterson authored
commit 62e96cf8 upstream. This patch calls get_write_access in function gfs2_setattr_chown, which merely increases inode->i_writecount for the duration of the function. That will ensure that any file closes won't delete the inode's multi-block reservation while the function is running. It also ensures that a multi-block reservation exists when needed for quota change operations during the chown. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
- 20 Jan, 2014 3 commits
-
-
Linus Torvalds authored
-
Ilia Mirkin authored
Since commit 61b365a5 ("drm/nouveau: populate master subdev pointer only when fully constructed"), the nouveau_mxm(bios) call will return NULL, since it's still being called from the constructor. Instead, pass the mxm pointer via the unused data field. See https://bugs.freedesktop.org/show_bug.cgi?id=73791Reported-by:
Andreas Reis <andreas.reis@gmail.com> Tested-by:
Ilia Mirkin <imirkin@alum.mit.edu> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull last-minute ACPI fix from Rafael Wysocki: "This reverts a commit that causes the Alan Cox' ASUS T100TA to "crash and burn" during boot if the Baytrail pinctrl driver is compiled in" * tag 'acpi-3.13-fixup' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs"
-
- 19 Jan, 2014 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: - an s2ram related fix on AMD systems - a perf fault handling bug that is relatively old but which has become much easier to trigger in v3.13 after commit e00b12e6 ("perf/x86: Further optimize copy_from_user_nmi()") * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h x86, mm, perf: Allow recursive faults from interrupts
-
