- 11 May, 2012 7 commits
-
-
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:
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:
Chris Ball <cjb@laptop.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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 33 commits
-
-
Greg Kroah-Hartman authored
-
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:
-
Jesse Sung authored
commit c0190925 upstream. Add another vendor specific ID for BCM20702A0. output of usb-devices: T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21e3 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=9439E5CBF66C C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> 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:
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:
-
Tomoya MORINAGA authored
commit 92b3a5c1 upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by:
Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
-
Danny Kukawka authored
commit de3bd7e6 upstream. Fix for: drivers/spi/spi-topcliff-pch.c: In function ‘pch_spi_handler_sub’: drivers/spi/spi-topcliff-pch.c:325:17: warning: ‘bpw_len’ may be used uninitialized in this function [-Wuninitialized] drivers/spi/spi-topcliff-pch.c:325:42: warning: ‘rx_index’ may be used uninitialized in this function [-Wuninitialized] drivers/spi/spi-topcliff-pch.c:325:42: warning: ‘tx_index’ may be used uninitialized in this function [-Wuninitialized] Move usage of tx_index, rx_index and bpw_len into the same block as where they are set to prevent uninitialized usage. v2: instead of init variables with 0 move the whole block [This patch title "warnings" makes you think "This patch is not for bug fix". However, this patch surely patch for bug fix.] Signed-off-by:
Danny Kukawka <danny.kukawka@bisect.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:
-
Dan Carpenter authored
commit 73f98eab upstream. pch_gbe_validate_option() modifies 32 bits of memory but we pass &hw->phy.autoneg_advertised which only has 16 bits and &hw->mac.fc which only has 8 bits. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Darren Hart authored
commit 2b53d078 upstream. If the MAC is invalid or not implemented, do not abort the probe. Issue a warning and prevent bringing the interface up until a MAC is set manually (via ifconfig $IFACE hw ether $MAC). Tested on two platforms, one with a valid MAC, the other without a MAC. The real MAC is used if present, the interface fails to come up until the MAC is set on the other. They successfully get an IP over DHCP and pass a simple ping and login over ssh test. This is meant to allow the Inforce SYS940X development board: http://www.inforcecomputing.com/SYS940X_ECX.html (and others suffering from a missing MAC) to work with the mainline kernel. Without this patch, the probe will fail and the interface will not be created, preventing the user from configuring the MAC manually. This does not make any attempt to address a missing or invalid MAC for the pch_phub driver. Signed-off-by:
Darren Hart <dvhart@linux.intel.com> CC: Arjan van de Ven <arjan@linux.intel.com> CC: Alan Cox <alan@linux.intel.com> CC: Tomoya MORINAGA <tomoya.rohm@gmail.com> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: "David S. Miller" <davem@davemloft.net> CC: Paul Gortmaker <paul.gortmaker@windriver.com> CC: Jon Mason <jdmason@kudzu.us> CC: Mark Brown <broonie@opensource.wolfsonmicro.com> CC: David Laight <David.Laight@ACULAB.COM> CC: Joe Perches <joe@perches.com> 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 83331040 upstream. ISSUE: USB Suspend interrupts occur frequently. CAUSE: When it is called pch_udc_reconnect() in USB Suspend, it repeats reset and Suspend. SOLUTION: pch_udc_reconnect() does not enable all interrupts. When an enumeration event occurred the driver enables all interrupts. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Tomoya MORINAGA authored
commit 1c575d2d upstream. ISSUE: After a USB cable is connect/disconnected, the system rarely freezes. CAUSE: Since the USB device controller cannot know to disconnect the USB cable, when it is used without detecting VBUS by GPIO, the UDC driver does not notify to USB Gadget. Since USB Gadget cannot know to disconnect, a false setting occurred when the USB cable is connected/disconnect repeatedly. Signed-off-by:
-
Tomoya MORINAGA authored
commit 84566abb upstream. ISSUE: After USB Suspend, a system rarely freezes. CAUSE: When USB Suspend occurred, the driver is not notifying a gadget of the event. Signed-off-by:
-
Tomoya MORINAGA authored
commit c802672c upstream. ISSUE: If the return value of pch_udc_pcd_init() is False, the return value of this function is unsettled. Since pch_udc_pcd_init() always returns 0, there is not actually the issue. CAUSE: If pch_udc_pcd_init() is True, the variable, retval, is not set for an appropriate value. Signed-off-by:
-
Tomoya MORINAGA authored
commit c50a3bff upstream. ISSUE: When the driver notifies a gadget of a disconnect event, a system rarely freezes. CAUSE: When the driver calls dev->driver->disconnect(), it is not calling spin_unlock(). Signed-off-by:
-
Axel Lin authored
commit d166370a upstream. This bug was introduced by commit d568a681 "gpio-pch: add spinlock in suspend/resume processing" which adds a spinlock to struct pch_gpio but never init the spinlock. Reported-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
-
Tomoya MORINAGA authored
commit 868fea05 upstream. ML7831 is companion chip for Intel Atom E6xx series. Signed-off-by:
-
Johan Hovold authored
commit 94324962 upstream. Make sure hci_dev_open returns immediately if hci_dev_unregister has been called. This fixes a race between hci_dev_open and hci_dev_unregister which can lead to a NULL-pointer dereference. Bug is 100% reproducible using hciattach and a disconnected serial port: 0. # hciattach -n /dev/ttyO1 any noflow 1. hci_dev_open called from hci_power_on grabs req lock 2. hci_init_req executes but device fails to initialise (times out eventually) 3. hci_dev_open is called from hci_sock_ioctl and sleeps on req lock 4. hci_uart_tty_close calls hci_dev_unregister and sleeps on req lock in hci_dev_do_close 5. hci_dev_open (1) releases req lock 6. hci_dev_do_close grabs req lock and returns as device is not up 7. hci_dev_unregister sleeps in destroy_workqueue 8. hci_dev_open (3) grabs req lock, calls hci_init_req and eventually sleeps 9. hci_dev_unregister finishes, while hci_dev_open is still running... [ 79.627136] INFO: trying to register non-static key. [ 79.632354] the code is fine but needs lockdep annotation. [ 79.638122] turning off the locking correctness validator. [ 79.643920] [<c00188bc>] (unwind_backtrace+0x0/0xf8) from [<c00729c4>] (__lock_acquire+0x1590/0x1ab0) [ 79.653594] [<c00729c4>] (__lock_acquire+0x1590/0x1ab0) from [<c00733f8>] (lock_acquire+0x9c/0x128) [ 79.663085] [<c00733f8>] (lock_acquire+0x9c/0x128) from [<c0040a88>] (run_timer_softirq+0x150/0x3ac) [ 79.672668] [<c0040a88>] (run_timer_softirq+0x150/0x3ac) from [<c003a3b8>] (__do_softirq+0xd4/0x22c) [ 79.682281] [<c003a3b8>] (__do_softirq+0xd4/0x22c) from [<c003a924>] (irq_exit+0x8c/0x94) [ 79.690856] [<c003a924>] (irq_exit+0x8c/0x94) from [<c0013a50>] (handle_IRQ+0x34/0x84) [ 79.699157] [<c0013a50>] (handle_IRQ+0x34/0x84) from [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) [ 79.708648] [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<c037499c>] (__irq_usr+0x3c/0x60) [ 79.718048] Exception stack(0xcf281fb0 to 0xcf281ff8) [ 79.723358] 1fa0: 0001e6a0 be8dab00 0001e698 00036698 [ 79.731933] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000 [ 79.740509] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff [ 79.747497] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 79.756011] pgd = cf3b4000 [ 79.758850] [00000000] *pgd=8f0c7831, *pte=00000000, *ppte=00000000 [ 79.765502] Internal error: Oops: 80000007 [#1] [ 79.770294] Modules linked in: [ 79.773529] CPU: 0 Tainted: G W (3.3.0-rc6-00002-gb5d5c879 #421) [ 79.781066] PC is at 0x0 [ 79.783721] LR is at run_timer_softirq+0x16c/0x3ac [ 79.788787] pc : [<00000000>] lr : [<c0040aa4>] psr: 60000113 [ 79.788787] sp : cf281ee0 ip : 00000000 fp : cf280000 [ 79.800903] r10: 00000004 r9 : 00000100 r8 : b6f234d0 [ 79.806427] r7 : c0519c28 r6 : cf093488 r5 : c0561a00 r4 : 00000000 [ 79.813323] r3 : 00000000 r2 : c054eee0 r1 : 00000001 r0 : 00000000 [ 79.820190] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 79.827728] Control: 10c5387d Table: 8f3b4019 DAC: 00000015 [ 79.833801] Process gpsd (pid: 1265, stack limit = 0xcf2802e8) [ 79.839965] Stack: (0xcf281ee0 to 0xcf282000) [ 79.844573] 1ee0: 00000002 00000000 c0040a24 00000000 00000002 cf281f08 00200200 00000000 [ 79.853210] 1f00: 00000000 cf281f18 cf281f08 00000000 00000000 00000000 cf281f18 cf281f18 [ 79.861816] 1f20: 00000000 00000001 c056184c 00000000 00000001 b6f234d0 c0561848 00000004 [ 79.870452] 1f40: cf280000 c003a3b8 c051e79c 00000001 00000000 00000100 3fa9e7b8 0000000a [ 79.879089] 1f60: 00000025 cf280000 00000025 00000000 00000000 b6f234d0 00000000 00000004 [ 79.887756] 1f80: 00000000 c003a924 c053ad38 c0013a50 fa200000 cf281fb0 ffffffff c0008530 [ 79.896362] 1fa0: 0001e6a0 0000aab8 80000010 c037499c 0001e6a0 be8dab00 0001e698 00036698 [ 79.904998] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000 [ 79.913665] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff 00fbf700 04ffff00 [ 79.922302] [<c0040aa4>] (run_timer_softirq+0x16c/0x3ac) from [<c003a3b8>] (__do_softirq+0xd4/0x22c) [ 79.931945] [<c003a3b8>] (__do_softirq+0xd4/0x22c) from [<c003a924>] (irq_exit+0x8c/0x94) [ 79.940582] [<c003a924>] (irq_exit+0x8c/0x94) from [<c0013a50>] (handle_IRQ+0x34/0x84) [ 79.948913] [<c0013a50>] (handle_IRQ+0x34/0x84) from [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) [ 79.958404] [<c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<c037499c>] (__irq_usr+0x3c/0x60) [ 79.967773] Exception stack(0xcf281fb0 to 0xcf281ff8) [ 79.973083] 1fa0: 0001e6a0 be8dab00 0001e698 00036698 [ 79.981658] 1fc0: 0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000 [ 79.990234] 1fe0: 0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff [ 79.997161] Code: bad PC value [ 80.000396] ---[ end trace 6f6739840475f9ee ]--- [ 80.005279] Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by:
Johan Hovold <jhovold@gmail.com> Acked-by:
-
Sarah Sharp authored
commit c7713e73 upstream. The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering that the xHCI registers are saved and restored in. It moves the interrupt pending (IMAN) and interrupt control (IMOD) registers to be saved and restored last. I believe that's because the host controller may attempt to fetch the event ring table when interrupts are re-enabled. Therefore we need to restore the event ring registers before we re-enable interrupts. This should be backported to kernels as old as 2.6.37, that contain the commit 5535b1d5 "USB: xHCI: PCI power management implementation" Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by:
Elric Fu <elricfu1@gmail.com> Cc: Andiry Xu <andiry.xu@amd.com> Signed-off-by:
-
Rajkumar Manoharan authored
commit 2ee0a070 upstream. Currently the maximum noise floor limit is set as too high (-60dB). The assumption of having a higher threshold limit is that it would help de-sensitize the receiver (reduce phy errors) from continuous interference. But when we have a bursty interference where there are collisions and then free air time and if the receiver is desensitized too much, it will miss the normal packets too. Lets make use of chips specific min, nom and max limits always. This patch helps to improve the connection stability in congested networks. Cc: Paul Stewart <pstew@google.com> Tested-by:
Gary Morain <gmorain@google.com> Signed-off-by:
Madhan Jaganathan <madhanj@qca.qualcomm.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.0/3.2: adjust context] Signed-off-by:
-
Eric Paris authored
commit d52fc5dd upstream. If a process increases permissions using fcaps all of the dangerous personality flags which are cleared for suid apps should also be cleared. Thus programs given priviledge with fcaps will continue to have address space randomization enabled even if the parent tried to disable it to make it easier to attack. Signed-off-by:
Eric Paris <eparis@redhat.com> Reviewed-by:
-
Linus Walleij authored
commit c3d8b76f upstream. Commit 360f748b204275229f8398cb2f9f53955db1503b "serial: PL011: clear pending interrupts" attempts to clear interrupts by writing to a yet-unassigned memory address. This fixes the issue. The breaking patch is marked for stable so should be carried along with the other patch. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Pitre <nico@fluxnic.net> Reported-by:
Viresh Kumar <viresh.kumar@st.com> Signed-off-by:
-
Linus Walleij authored
commit 9b96fbac upstream. Chanho Min reported that when the boot loader transfers control to the kernel, there may be pending interrupts causing the UART to lock up in an eternal loop trying to pick tokens from the FIFO (since the RX interrupt flag indicates there are tokens) while in practice there are no tokens - in fact there is only a pending IRQ flag. This patch address the issue with a combination of two patches suggested by Russell King that clears and mask all interrupts at probe() and clears any pending error and RX interrupts at port startup time. We suspect the spurious interrupts are a side-effect of switching the UART from FIFO to non-FIFO mode. Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Reported-by:
Chanho Min <chanho0207@gmail.com> Suggested-by:
Russell King <linux@arm.linux.org.uk> Signed-off-by:
Jong-Sung Kim <neidhard.kim@lge.com> Signed-off-by:
-
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:
-
Alex He authored
commit 95018a53 upstream. Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable bits will be cleared to zero and flag bits 29:31 are also cleared to zero. Other bits should be presvered as Table 146. This patch should be backported to kernels as old as 2.6.31. Signed-off-by:
Alex He <alex.he@amd.com> Signed-off-by:
-
Elric Fu authored
commit 457a4f61 upstream. The suspend operation of VIA xHCI host have some issues and hibernate operation works fine, so The XHCI_RESET_ON_RESUME quirk is added for it. This patch should base on "xHCI: Don't write zeroed pointer to xHC registers" that is released by Sarah. Otherwise, the host system error will ocurr in the hibernate operation process. This should be backported to stable kernels as old as 2.6.37, that contain the commit c877b3b2 "xhci: Add reset on resume quirk for asrock p67 host". Signed-off-by:
-
Elric Fu authored
commit d8aec3db upstream. When the Seagate Goflex USB3.0 device is attached to VIA xHCI host, sometimes the device will downgrade mode to high speed. By the USB analyzer, I found the device finished the link training process and worked at superspeed mode. But the device descriptor got from the device shows the device works at 2.1. It is very strange and seems like the device controller of Seagate Goflex has a little confusion. The first 8 bytes of device descriptor should be: 12 01 00 03 00 00 00 09 But the first 8 bytes of wrong device descriptor are: 12 01 10 02 00 00 00 40 The wrong device descriptor caused the initialization of mass storage failed. After a while, the device would be recognized as a high speed device and works fine. This patch will warm reset the device to fix the issue after finding the bcdUSB field of device descriptor isn't 0x0300 but the speed mode of device is superspeed. This patch should be backported to kernels as old as 3.2, or ones that contain the commit 75d7cf72 "usbcore: refine warm reset logic". Signed-off-by:
Andiry Xu <Andiry.Xu@amd.com> Acked-by:
Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by:
-
Sarah Sharp authored
commit fb3d85bc upstream. The xhci_save_registers() function saved the event ring dequeue pointer in the s3 register structure, but xhci_restore_registers() never restored it. No other code in the xHCI successful resume path would ever restore it either. Fix that. This should be backported to kernels as old as 2.6.37, that contain the commit 5535b1d5 "USB: xHCI: PCI power management implementation". Signed-off-by:
-
