- 27 Apr, 2012 21 commits
-
-
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:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
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:
-
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:
-
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:
-
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:
Mauro Carvalho Chehab <mchehab@redhat.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:
David S. Miller <davem@davemloft.net> 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:
-
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 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:
Takashi Iwai <tiwai@suse.de> 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 19 commits
-
-
Greg Kroah-Hartman authored
-
Martin Schwidefsky authored
commit cd94154c upstream. Git commit 36409f63 "use generic RCU page-table freeing code" introduced a tlb flushing bug. Partially revert the above git commit and go back to s390 specific page table flush code. For s390 the TLB can contain three types of entries, "normal" TLB page-table entries, TLB combined region-and-segment-table (CRST) entries and real-space entries. Linux does not use real-space entries which leaves normal TLB entries and CRST entries. The CRST entries are intermediate steps in the page-table translation called translation paths. For example a 4K page access in a three-level page table setup will create two CRST TLB entries and one page-table TLB entry. The advantage of that approach is that a page access next to the previous one can reuse the CRST entries and needs just a single read from memory to create the page-table TLB entry. The disadvantage is that the TLB flushing rules are more complicated, before any page-table may be freed the TLB needs to be flushed. In short: the generic RCU page-table freeing code is incorrect for the CRST entries, in particular the check for mm_users < 2 is troublesome. This is applicable to 3.0+ kernels. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Dave Airlie authored
commit a09d431f upstream. When the force changes went in back in 3.3.0, we ended up returning disconnected in the !force case, and the connected in when forced, as it hit the hardcoded check. Fix it so all exits go via the hardcoded check and stop spurious modesets on platforms with hardcoded EDIDs. Reported-by: Evan McNabb (Red Hat) Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 16a5e32b upstream. My rv515 card is very flaky with msi enabled. Every so often it loses a rearm and never comes back, manually banging the rearm brings it back. Reviewed-by:
-
Takashi Iwai authored
commit e3632507 upstream. The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms: fix analog load detection on DVI-I connectors] is obviously wrong, and it's the culprit of the regression on my workstation with DVI-analog connection resulting in the blank output. Fixed the typo now. Signed-off-by:
-
Kees Cook authored
commit bdbb776f upstream. It was possible to extract the robust list head address from a setuid process if it had used set_robust_list(), allowing an ASLR info leak. This changes the permission checks to be the same as those used for similar info that comes out of /proc. Running a setuid program that uses robust futexes would have had: cred->euid != pcred->euid cred->euid == pcred->uid so the old permissions check would allow it. I'm not aware of any setuid programs that use robust futexes, so this is just a preventative measure. (This patch is based on changes from grsecurity.) Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: David Howells <dhowells@redhat.com> Cc: Serge E. Hallyn <serge.hallyn@canonical.com> Cc: kernel-hardening@lists.openwall.com Cc: spender@grsecurity.net Link: http://lkml.kernel.org/r/20120319231253.GA20893@www.outflux.netSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Cho, Yu-Chen authored
commit 07c0ea87 upstream. Add Atheros maryann 0cf3:311d PIDVID support This module is AR3012 Series. Include /sys/kernel/debug/usb/devices output here for reference before: T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=311d Rev= 0.01 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms after: T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=311d Rev= 0.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Cho, Yu-Chen <acho@suse.com> cked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Eran authored
commit 9498ba7a upstream. The bluetooth module in the Asus UX31/UX21 is based on Atheros AR3012 and requires a firmware to be uploaded before it's usable. output of usb-devices for this module: T: Bus=01 Lev=02 Prnt=02 Port=07 Cnt=03 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3375 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Eran <eran@over-here.org> Tested-by:
Michal Labedzki <michal.labedzki@tieto.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
NeilBrown authored
commit afbaa90b upstream. If a bitmap is added while the array is active, it is possible for bitmap_daemon_work to run while the bitmap is being initialised. This is particularly a problem if bitmap_daemon_work sees bitmap->filemap as non-NULL before it has been filled in properly. So hold bitmap_info.mutex while filling in ->filemap to prevent problems. This patch is suitable for any -stable kernel, though it might not apply cleanly before about 3.1. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Tomoya MORINAGA authored
commit ca7fe2db upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by:
-
Tomoya MORINAGA authored
commit c43f1508 upstream. Currently, executing suspend/hibernation, memory access violation occurs. In pch_dma_save_regs() called by suspend(), you can see the following code. static void pch_dma_save_regs(struct pch_dma *pd) { snip... list_for_each_entry_safe(chan, _c, &pd->dma.channels, device_node) { pd_chan = to_pd_chan(chan); pd->ch_regs[i].dev_addr = channel_readl(pd_chan, DEV_ADDR); pd->ch_regs[i].mem_addr = channel_readl(pd_chan, MEM_ADDR); pd->ch_regs[i].size = channel_readl(pd_chan, SIZE); pd->ch_regs[i].next = channel_readl(pd_chan, NEXT); i++; } } Max loop count is 12 defined at pci_table. So, this caused memory access violation. This patch fixes the issue - Modify array size (MAX_CHAN_NR) Signed-off-by:
Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Signed-off-by:
-
Tomoya MORINAGA authored
commit 0b052f4a upstream. Currently, Mode-Control register is accessed by read-modify-write. According to DMA hardware specifications datasheet, prohibits this method. Because this register resets to 0 by DMA HW after DMA transfer completes. Thus, current read-modify-write processing can cause unexpected behavior. The datasheet says in case of writing Mode-Control register, set the value for only target channel, the others must set '11b'. e.g. Set DMA0=01b DMA11=10b CTL0=33333331h CTL2=00002333h NOTE: CTL0 includes DMA0~7 Mode-Control register. CTL2 includes DMA8~11 Mode-Control register. This patch modifies the issue. Signed-off-by:
Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Alexander Stein authored
commit 70f18915 upstream. Fix for the following INFO message ================================= [ INFO: inconsistent lock state ] 2.6.39+ #89 --------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes: (&(&pd_chan->lock)->rlock){?.....}, at: [<c123b9a1>] pdc_desc_get+0x16/0xab {HARDIRQ-ON-W} state was registered at: [<c104fe28>] mark_irqflags+0xbd/0x11a [<c1050386>] __lock_acquire+0x501/0x6bb [<c1050945>] lock_acquire+0x63/0x7b [<c131c51d>] _raw_spin_lock_bh+0x43/0x51 [<c123bee4>] pd_alloc_chan_resources+0x92/0x11e [<c123ad62>] dma_chan_get+0x9b/0x107 [<c123b2d1>] __dma_request_channel+0x61/0xdc [<c11ba24b>] pch_request_dma+0x61/0x19e [<c11bb3b8>] pch_uart_startup+0x16a/0x1a2 [<c11b8446>] uart_startup+0x87/0x147 [<c11b9183>] uart_open+0x117/0x13e [<c11a5c7d>] tty_open+0x23c/0x34c [<c1097705>] chrdev_open+0x140/0x15f [<c10930a6>] __dentry_open.clone.14+0x14a/0x22b [<c1093dfb>] nameidata_to_filp+0x36/0x40 [<c109f28b>] do_last+0x513/0x635 [<c109f4af>] path_openat+0x9c/0x2aa [<c109f6e4>] do_filp_open+0x27/0x69 [<c1093f02>] do_sys_open+0xfd/0x184 [<c1093fad>] sys_open+0x24/0x2a [<c131d58c>] sysenter_do_call+0x12/0x32 irq event stamp: 2522 hardirqs last enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52 hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34 softirqs last enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4 other info that might help us debug this: 2 locks held by rs232/822: #0: (&tty->atomic_write_lock){+.+.+.}, at: [<c11a4b7a>] tty_write_lock+0x14/0x3c #1: (&port_lock_key){-.....}, at: [<c11bad72>] pch_uart_interrupt+0x17/0x1e9 stack backtrace: Pid: 822, comm: rs232 Not tainted 2.6.39+ #89 Call Trace: [<c1319f90>] ? printk+0x19/0x1b [<c104f893>] print_usage_bug+0x184/0x18f [<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e [<c104f943>] mark_lock_irq+0xa5/0x1f6 [<c104fc9c>] mark_lock+0x208/0x2d7 [<c104fdc0>] mark_irqflags+0x55/0x11a [<c1050386>] __lock_acquire+0x501/0x6bb [<c10042ee>] ? dump_trace+0x92/0xb6 [<c1050945>] lock_acquire+0x63/0x7b [<c123b9a1>] ? pdc_desc_get+0x16/0xab [<c131c2d0>] _raw_spin_lock+0x3e/0x4c [<c123b9a1>] ? pdc_desc_get+0x16/0xab [<c123b9a1>] pdc_desc_get+0x16/0xab [<c10504d8>] ? __lock_acquire+0x653/0x6bb [<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb [<c1006c3f>] ? nommu_map_sg+0x6e/0x81 [<c11bace6>] dma_handle_tx+0x2cf/0x344 [<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9 [<c11baebb>] pch_uart_interrupt+0x160/0x1e9 [<c10642fb>] handle_irq_event_percpu+0x25/0x127 [<c1064429>] handle_irq_event+0x2c/0x43 [<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84 [<c1065eb9>] handle_edge_irq+0xac/0xce <IRQ> [<c1003ecb>] ? do_IRQ+0x38/0x9d [<c131db2e>] ? common_interrupt+0x2e/0x34 [<c105007b>] ? __lock_acquire+0x1f6/0x6bb [<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52 [<c11b798b>] ? uart_start+0x2d/0x32 [<c11b7998>] ? uart_flush_chars+0x8/0xa [<c11a7962>] ? n_tty_write+0x12c/0x1c6 [<c1027a73>] ? try_to_wake_up+0x251/0x251 [<c11a4d0b>] ? tty_write+0x169/0x1dc [<c11a7836>] ? n_tty_ioctl+0xb7/0xb7 [<c1094841>] ? vfs_write+0x91/0x10d [<c11a4ba2>] ? tty_write_lock+0x3c/0x3c [<c1094a69>] ? sys_write+0x3e/0x63 [<c131d58c>] ? sysenter_do_call+0x12/0x32 Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Tested-by:
-
Tomoya MORINAGA authored
commit c3d4913c upstream. ISSUE: In case PCH_DMA with I2S communications with ch8~ch11, sometimes I2S data is not send correctly. CAUSE: The following patch I submitted before was not enough modification for supporting DMA ch8~ch11. The modification for status register of ch8~11 was not enough. pch_dma: Support I2S for ML7213 IOH author Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900) committer Vinod Koul <vinod.koul@intel.com> Mon, 9 May 2011 11:42:23 +0000 (16:42 +0530) commit 194f5f27 tree c9d4903ea02b18939a4f390956a48be1a3734517 parent 60092d0b This patch fixes the issue. We can confirm PCH_DMA with I2S communications with ch8~ch11 works well. Signed-off-by:
-
Tomoya MORINAGA authored
commit 64d91cfa upstream. Currently, ".setup" function is not set. As a result, when detecting our IOH's uart device without pch_uart, kernel panic occurs at the following of pciserial_init_ports(). for (i = 0; i < nr_ports; i++) { if (quirk->setup(priv, board, &serial_port, i)) break; So, this patch adds the ".setup" function. We can use pci_default_setup because our IOH's uart is compatible with 16550. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Tomoya MORINAGA authored
commit 6c4b47d2 upstream. Currently, PCIe bus number is set as fixed value "2". However, PCIe bus number is not always "2". This patch sets bus number using probe() parameter. Signed-off-by:
-
Jonghwan Choi authored
commit 51b79bee upstream. Add missing "personality.h" security/commoncap.c: In function 'cap_bprm_set_creds': security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function) security/commoncap.c:510: error: (Each undeclared identifier is reported only once security/commoncap.c:510: error: for each function it appears in.) Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
-
Lin Ming authored
commit 8931d9ea upstream. Allow referenced objects to be in a different scope. http://www.acpica.org/bugzilla/show_bug.cgi?id=937 http://marc.info/?l=linux-acpi&m=131636632718222&w=2 ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110112/psargs-359) ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110112/nsinit-349) Scope (_SB) { Name (RAMB, 0xDF5A1018) OperationRegion (\RAMW, SystemMemory, RAMB, 0x00010000) } For above ASL code, we need to save scope node(\_SB) to lookup the argument node(\_SB.RAMB). Reported-by:
Jim Green <student.northwestern@gmail.com> Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
-
Tomoya MORINAGA authored
commit 731ad81e upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by:
-
