- 11 May, 2012 39 commits
-
-
Shubhrajyoti D authored
commit ad579699 upstream. pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message. Cc: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Kishon Vijay Abraham I authored
commit 3006dc8c upstream. pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
commit 92b0abf8 upstream. usb: gadget: eliminate NULL pointer dereference (bugfix) This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands: $ insmod g_ffs.ko $ mount -t functionfs func /dev/usbgadget $ ./null where null.c is: #include <fcntl.h> #include <linux/usb/functionfs.h> int main(void) { int fd = open("/dev/usbgadget/ep0", O_RDWR); ioctl(fd, FUNCTIONFS_CLEAR_HALT); return 0; } Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Alan Stern authored
commit 320cd1e7 upstream. This patch (as1548) fixes a recently-introduced incompatibility between the UDC core and the dummy-hcd driver. Commit 8ae8090c (usb: gadget: udc-core: fix asymmetric calls in remove_driver) moved the usb_gadget_udc_stop() call in usb_gadget_remove_driver() below the usb_gadget_disconnect() call. As a result, usb_gadget_disconnect() gets called at a time when the gadget driver believes it has been unbound but dummy-hcd believes it has not. A nasty error ensues when dummy-hcd calls the gadget driver's disconnect method a second time. To fix the problem, this patch moves the gadget driver's unbind notification after the usb_gadget_disconnect() call. Now nothing happens between the two unbind notifications, so nothing goes wrong. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
commit 83a787a7 upstream. commit 6d258a4c (usb: gadget: udc-core: stop UDC on device-initiated disconnect) introduced another case of asymmetric calls when issuing a device-initiated disconnect. Fix it. Reported-by:
-
Kishon Vijay Abraham I authored
commit 8ae8090c upstream. During modprobe of gadget driver, pullup is called after udc_start. In order to make the exit path symmetric when removing a gadget driver, call pullup before ->udc_stop. This is needed to avoid issues with PM where udc_stop disables the module completely (put IP in reset state, cut functional and interface clocks, and so on), which prevents us from accessing the IP's address space, thus creating the possibility of an abort exception when we try to access IP's address space after clocks are off. Signed-off-by:
Partha Basak <p-basak2@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit 6d258a4c upstream. When we want to do device-initiated disconnect, let's make sure we stop the UDC in order to e.g. allow lower power states to be achieved by turning off unnecessary clocks and/or stoping PHYs. When reconnecting, call ->udc_start() again to make sure UDC is reinitialized. Signed-off-by:
-
Alan Stern authored
commit 8963c487 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alan Stern authored
commit 2fbe2bf1 upstream. This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register. Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
-
Alan Stern authored
commit dc75ce9d upstream. This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended. Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended. In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases. Signed-off-by:
-
Bjørn Mork authored
commit 749541d1 upstream. These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers. We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Julia Lawall authored
commit d3a7b83f upstream. tty_unlock is used on all other exits from the function. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Tomoya MORINAGA authored
commit af6d17cd upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by:
-
Yuri Matylitski authored
commit 2d5733fc upstream. Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT. Signed-off-by:
Yuri Matylitski <ym@tekinsoft.com> Acked-by:
Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by:
-
Shaohua Li authored
commit 99aa7846 upstream. flush request is issued in transaction commit code path, so looks using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. I saw btrfs and dm get it right, but ext4, xfs and md are using GFP. Signed-off-by:
Shaohua Li <shli@fusionio.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
NeilBrown authored
commit 30b8aa91 upstream. commit c744a65c md: don't set md arrays to readonly on shutdown. removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted. If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array. So only call __md_stop_writes() if the array has actually been activated. This patch is needed for any stable kernel which has had the above commit applied. Reported-by:
Christoph Nelles <evilazrael@evilazrael.de> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Hugh Dickins authored
commit aca50bd3 upstream. Mel reports a BUG_ON(slot == NULL) in radix_tree_tag_set() on s390 3.0.13: called from __set_page_dirty_nobuffers() when page_remove_rmap() tries to transfer dirty flag from s390 storage key to struct page and radix_tree. That would be because of reclaim's shrink_page_list() calling add_to_swap() on this page at the same time: first PageSwapCache is set (causing page_mapping(page) to appear as &swapper_space), then page->private set, then tree_lock taken, then page inserted into radix_tree - so there's an interval before taking the lock when the radix_tree slot is empty. We could fix this by moving __add_to_swap_cache()'s spin_lock_irq up before the SetPageSwapCache. But a better fix is simply to do what's five years overdue: Ken Chen introduced __set_page_dirty_no_writeback() (if !PageDirty TestSetPageDirty) for tmpfs to skip all the radix_tree overhead, and swap is just the same - it ignores the radix_tree tag, and does not participate in dirty page accounting, so should be using __set_page_dirty_no_writeback() too. s390 testing now confirms that this does indeed fix the problem. Reported-by:
Mel Gorman <mgorman@suse.de> Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Miller authored
commit e88aa7bb upstream. The symbol table on x86-64 starts to have entries that have names like: _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria. -------------------- FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h -------------------- These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code. So skip the symbol if it is not of type STT_OBJECT. Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Lukasz Kucharczyk authored
commit e55a4046 upstream. Signed-off-by:
Lukasz Kucharczyk <lukasz.kucharczyk@tieto.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Alexey Khoroshilov authored
commit e4459e16 upstream. If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
David Härdeman authored
commit d9b78695 upstream. Setting the correct mode is required by rc-core or scancodes won't be generated (which isn't very user-friendly). This one-line fix should be suitable for 3.4-rc2. Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
-
Arend van Spriel authored
commit badc4f07 upstream. There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211. This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3. Tested-by:
Francesco Saverio Schiavarelli <fschiava@libero.it> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Brett Rudley <brudley@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Bing Zhao authored
commit 428ca8a7 upstream. The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Christian Riesch authored
commit 5b76d060 upstream. Under heavy load (flood ping) it is possible for the MDIO timeout to expire before the loop checks the GO bit again. This patch adds an additional check whether the operation was done before actually returning -ETIMEDOUT. To reproduce this bug, flood ping the device, e.g., ping -f -l 1000 After some time, a "timed out waiting for user access" warning may appear. And even worse, link may go down since the PHY reported a timeout. Signed-off-by:
Christian Riesch <christian.riesch@omicron.at> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by:
-
Oliver Neukum authored
commit 5bd7b419 upstream. Fatal errors such as a device disconnect must not trigger error handling. The error returns must be checked. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
commit 9426cd05 upstream. del_timer_sync() cannot be used in interrupt. Replace it with del_timer() and a flag Signed-off-by:
-
Tomoki Sekiyama authored
commit 532f17b5 upstream. Current probing code is setting URB_NO_TRANSFER_DMA_MAP flag into a wrong urb structure, and this causes BUG_ON with some USB host implementations. This patch fixes the issue. Signed-off-by:
Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by:
-
Tomoki Sekiyama authored
commit 523fc5c1 upstream. Removes allocation of coherent buffer for the control-request setup-packet buffer from the yurex driver. Using coherent buffers for setup-packet is obsolete and does not work with some USB host implementations. Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit 3066616c upstream. A rather annoying and common case is when booting a PVonHVM guest and exposing the PV KBD and PV VFB - as broken toolstacks don't always initialize the backends correctly. Normally The HVM guest is using the VGA driver and the emulated keyboard for this (though upstream version of QEMU implements PV KBD, but still uses a VGA driver). We provide a very basic two-stage wait mechanism - where we wait for 30 seconds for all devices, and then for 270 for all them except the two mentioned. That allows us to wait for the essential devices, like network or disk for the full 6 minutes. To trigger this, put this in your guest config: vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1'] instead of this: vnc=1 vnclisten="0.0.0.0" Acked-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> [v3: Split delay in non-essential (30 seconds) and essential devices per Ian and Stefano suggestion] [v4: Added comments per Stefano suggestion] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Stefano Stabellini authored
commit e8e937be upstream. Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap'ed by gntdev. Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. Signed-off-by:
-
Eric Bénard authored
commit b8915282 upstream. This was broken by me in 37865fe9 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read). Signed-off-by:
Eric Bénard <eric@eukrea.com> Acked-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Adrian Hunter authored
commit 28302812 upstream. eMMC v4.5 sanitize operation erases all copies of unmapped data. However trim or erase operations must be used first to unmap the required sectors. That was not being done. Fixes apply to linux 3.2 on. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Acked-by:
Jaehoon Chung <jh80.chung@samsung.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adrian Hunter authored
commit 7194efb8 upstream. eMMC v4.5 discard operation is significantly different from the existing trim operation because it is not guaranteed to work with the new sanitize operation. Consequently mmc_can_trim() is separated from mmc_can_discard(). Also the new discard operation does not result in the sectors being set to all-zeros, so discard_zeroes_data must not be set. In addition, the new discard has the same timeout as trim, but from v4.5 trim is defined to use the hc timeout. The timeout calculation is adjusted accordingly. Fixes apply to linux 3.2 on. Signed-off-by:
-
Paul Walmsley authored
commit 6aaec67d upstream. DMTIMER source selection on OMAP1 is broken. omap1_dm_timer_set_src() tries to use __raw_{read,write}l() to read from and write to physical addresses, but those functions take virtual addresses. sparse caught this: arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:50:13: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/timer.c:50:13: got unsigned int arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap1/timer.c:52:9: expected void const volatile [noderef] <asn:2>*<noident> arch/arm/mach-omap1/timer.c:52:9: got unsigned int Fix by using omap_{read,writel}(), just like the other users of the MOD_CONF_CTRL_1 register in the OMAP1 codebase. Of course, in the long term, removing omap_{read,write}l() is the appropriate thing to do; but this will take some work to do this cleanly. Looks like this was caused by 97933d6c (ARM: OMAP1: dmtimer: conversion to platform devices) that dangerously moved code and changed it in the same patch. Signed-off-by:
Paul Walmsley <paul@pwsan.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com> [tony@atomide.com: updated comments to include the breaking commit] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Alexander Shiyan authored
commit 7a6fbc9a upstream. Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result of call disable_irq from ISR. synchronize_irq waits for end of interrupt and goes to infinite loop. This patch fix this problem. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Takashi Iwai authored
commit d70f3632 upstream. ThinkPad 410,420,510,520 and X201 with cx50585 & co chips have the docking-station ports, but BIOS doesn't initialize for these pins. Thus, like the former X200, we need to set up the pins manually in the driver. The odd part is that the same PCI SSID is used for X200 and T400, thus we need to prepare individual fixup tables for cx5051 and others. Bugzilla entries: https://bugzilla.redhat.com/show_bug.cgi?id=808559 https://bugzilla.redhat.com/show_bug.cgi?id=806217 https://bugzilla.redhat.com/show_bug.cgi?id=810697Reported-by:
Josh Boyer <jwboyer@redhat.com> Reported-by:
Jens Taprogge <jens.taprogge@taprogge.org> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit ca3649de upstream. Some output pins on Conexant chips have no HP control bit, but the auto-parser initializes these pins unconditionally with PIN_HP. Check the pin-capability and avoid the HP bit if not supported. Signed-off-by:
-
Kent Yoder authored
commit 25c3d30c upstream. The current code only increments the upper 64 bits of the SHA-512 byte counter when the number of bytes hashed happens to hit 2^64 exactly. This patch increments the upper 64 bits whenever the lower 64 bits overflows. Signed-off-by:
Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Zeev Tarantov authored
[Patch not needed upstream as this is a backport build bugfix - gregkh gcc correctly complains: util/hist.c: In function ‘__hists__add_entry’: util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) for this new code: + if (he->ms.map != entry->ms.map) { + he->ms.map = entry->ms.map; + if (he->ms.map) + he->ms.map->referenced = true; + } because "entry" is a "struct hist_entry", not a pointer to a struct. In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested. Signed-off-by:Zeev Tarantov <zeev.tarantov@gmail.com> Cc: Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
- 22 Apr, 2012 1 commit
-
-
Greg Kroah-Hartman authored
-
