aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* gpu: pvr: Update to DDK 1.8@2198402Alistair Strachan2012-11-267-19/+34
| | | | | | | - Implemented a DC API change which queues a dummy display flip to workaround a rare and difficult to reproduce synchronization deadlock. - Eliminate log spam from Linux shrinker integration.
* OMAP4: hsmmc: fix race conditions in suspend/resume pathBalaji T K2012-08-161-11/+6
| | | | | | This reverts commit a15bf22cba9eec27a008331c4b8a095fc43ea6b7. Change-Id: I92f37aaa0a5b323b229c2e51b4176f837a5e1494
* Revert "OMAP4: hsmmc: fix race conditions in suspend/resume path"Todd Poynor2012-08-141-6/+6
| | | | | | | This reverts commit 1b8153cc8ca36697f4d1dbf36916fbe506d6cd95. Change-Id: I31ffd48debe6562a29d640554e6fe4a563aa4ad3 Signed-off-by: Todd Poynor <toddpoynor@google.com>
* OMAP: mcspi: Perform NULL pointer check before accessing cd->swap_datalinesBarbaros Tokaoglu2012-07-101-1/+1
| | | | Signed-off-by: Barbaros Tokaoglu <barbarost@gmail.com>
* OMAP4: hsmmc: fix race conditions in suspend/resume pathBalaji T K2012-06-191-6/+6
| | | | | | | | | using mmc_host_enable/disable causes race conditions. By using runtime pm framework during hsmmc suspend/resume, clock management integrity is kept, thereby avoid race conditions Change-Id: I34dac7d3aaacab82b82dedff610b3a5060cf72ce Signed-off-by: Mahesh Renduchintala <mahesh@ti.com>
* video: omap4: dsscomp: fix warning DSSCIOC_QUERY_DISPLAY range checkingErik Gilling2012-06-131-1/+1
| | | | | Change-Id: I3e45d0d27a31908dd2e3462bb823900af78d20e5 Signed-off-by: Erik Gilling <konkers@android.com>
* OMAP:DSSCOMP:Limit modedb_len in query ioctlMike J. Chen2012-06-131-1/+10
| | | | | | | | Add an argument sanity check/limit to prevent heap corruption attacks. Change-Id: Ib466af13dba8da6bd4d9b326cdc6b842c8f3caa7 Signed-off-by: Erik Gilling <konkers@android.com>
* OMAP4: DSSCOMP: Check user passed arg in ioctlMike J. Chen2012-06-131-0/+3
| | | | | | | | Prevent stack overflow if user passes in a value that's too large for num_ovl. Change-Id: I86a232544f8acc6a08eca00dfdb71db41f355341 Signed-off-by: Mike J. Chen <mjchen@google.com>
* video: omap2: retry hdcp aksv check after resetErik Gilling2012-06-121-1/+10
| | | | | | | The AKSV keys take some time to become valid Change-Id: Iba16108f1efc7884bfb967c9e61a097e31150508 Signed-off-by: Erik Gilling <konkers@android.com>
* OMAP4: MUSB: peripheral isoch in transfer supportRuchika Kharwar2012-05-241-3/+8
| | | | | | | | | | | | | This patch fixes the following 1. The logic that determines a short packet endpoint sizes to be a power of 2 number. This is typically not true for isochronous endpoints. 2. When a short/zero packet or DMA mode 0 is used, and TXPKTRDY is needed to be set by the CPU, the ISO bit should be set if its an isochronous transfer. 3. When a short/zero packet or DMA mode 0 is used, and TXPKTRDY is set by the CPU, g_giveback_request is deferred till the endpoint interrupt occurs. Change-Id: I87873496b90755cf78fd283ca996f17f02408dcd Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* Revert "OMAP4: MUSB: peripheral isoch IN endpt support"Ruchika Kharwar2012-05-242-36/+16
| | | | | | | | This reverts commit e1a51c83f7f0d81d256b38ccc1826656324ed212. This patch breaks USB tethering. Change-Id: I78708054f788f0eefe803a7feff5e59a12a75518 Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* usb: musb: Fix memory corruptionBenoit Goby2012-05-211-1/+1
| | | | | | | | | | rx_count, the number of bytes in the rx fifo, may be larger than the size of the transfer buffer. Make sure we don't overflow the transfer buffer in that case. Bug: 6497399 Change-Id: I5bcf6dd543f9da4ee22944aa6c41673f2cca4c1f Signed-off-by: Benoit Goby <benoit@android.com>
* OMAPDSS: DISPC: Fix rounding error in scaling decisionLajos Molnar2012-05-211-2/+2
| | | | | | | | | | | When checking if we are downscaling by more than a factor, we were dividing the source dimensions instead of multiplying back the target dimensions. This allowed downscaling by slightly more than the max supported downscaling, resulting in out-of-range register settings and ultimately SYNC_LOST. Change-Id: Ic039789c5011d64da870121eeb227a803af1fa83 Signed-off-by: Lajos Molnar <lajos@ti.com>
* gpu: pvr: Update to DDK 1.8@905891Ben Jones2012-05-142-57/+78
| | | | | | - Fix some bugs in the newly introduced memory pool code (b/6096575) Change-Id: I983f28e7c350ad72510b82b94e27d2cc103e10cd
* usb: musb: handle nuked ep dma interruptVikram Pandita2012-05-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User can trigger disabling of gadget at run time while the transfers are going on. Eg: On android doing: echo 0 > /sys/class/android_usb/android0/enable While a big file transfer is going on via PTP/MTP. In such a case, musb_gadget_disable() calls nuke() but the dma interrupt may still happen for an endpoint since hw would raise the interrupt in anycase. This can result in a NULL pointer access crash: [ 314.030426] PC is at txstate+0x74/0x20c [ 314.034759] LR is at musb_g_tx+0x140/0x204 [ 314.039489] pc : [<c03506f4>] lr : [<c0350bcc>] psr: 20000193 [ 314.039520] sp : c783bc68 ip : 00000002 fp : c783bc9c [ 314.052429] r10: 00000018 r9 : 00000000 r8 : 00000200 [ 314.058258] r7 : 00000000 r6 : fc0ab130 r5 : c781a410 r4 : c6caf640 [ 314.065643] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : c781a000 [ 315.083251] Backtrace: [ 315.086242] [<c0350680>] (txstate+0x0/0x20c) from [<c0350bcc>] (musb_g_tx+0x140/0x204) [ 315.095123] [<c0350a8c>] (musb_g_tx+0x0/0x204) from [<c034eb00>] (musb_dma_completion+0x40/0x54) [ 315.104980] [<c034eac0>] (musb_dma_completion+0x0/0x54) from [<c0351e6c>] (dma_controller_irq+0x118/0x184) [ 315.115661] [<c0351d54>] (dma_controller_irq+0x0/0x184) from [<c00d86b8>] (handle_irq_event_percpu+0x54/0x188) So put protection in code to handle possiblity of getting an interrupt for an endpoint that might have been already nuked. Change-Id: I565a586264a87458f3bb4fb49ff9c3e4905e3e3c Reported-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
* OMAP3+: DVFS: ensure proper volt config if curr_volt==new_voltNishanth Menon2012-05-101-0/+7
| | | | | | | | | | | | | | | | At times when current_volt is same as new voltage, voltdm_scale is not invoked. Since, vp_err_gain update and voltdm->curr_volt update is done as part of vc_prescale and post_scale invoked as part of scale call, these are left configured to old OPP values even if we are moving to a new OPP. Update these when we detect voltdm_scale is not being invoked, but new OPP Vnom is detected. Change-Id: Ic45d5a51edb4e5fe526529c6040cd014907b560e Reported-by: Honda Kenji <x0092217@ti.com> Reported-by: Maki Tanaka <m-tanaka1@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP3+: ABB: make the pre and post scale decision based off VnomNishanth Menon2012-05-103-28/+83
| | | | | | | | | | | | | | | | | | | | | | | Currently the ABB LDO prescale and post scale configurations are done based off voltdm_scale. However when Vsr(SR adjusted voltage) of the current OPP is the same as Vnom(nominal voltage) of the new OPP, this results in voltdm_scale not being called. This has a side-effect of prescale and postscale of ABB not being invoked either. In case where the new OPP requires FBB, this will result in device failure. The right procedure is to move the prescale and postscale notifier out of the voltage scale API, instead have it on top of dvfs path and depend on nominal voltage scaling direction to give a proper trigger on need basis. NOTE: ABB prescale is skipped in pm.c initial configuration to take care of various types of bad and correct bootloader configuration. Change-Id: Ie953f515ab6182d6fa9be85d0ea83228db63d969 Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP3+: voltage: omap_voltage_get_voltdata searches only for VnomNishanth Menon2012-05-101-2/+1
| | | | | | | | | | | | | | | | | | | Operational voltage comparisons are wrong in this search since we can end up with scenarios such as the following: OPP1 Volt_nominal == OPP2 Volt_calibrated if the search for Volt_calibrated of OPP2 is done, if OPP1 appears earlier in the array, this will result in returning the OPP1's volt_data pointer which is wrong. In such a double match, there is no real "correct selection" possible. The current users of this function omap_voltage_get_voltdata are dvfs.c and pm.c (setting up boot voltage) - both these use Vnom for search, so it is safe to remove the check for operational voltage and search for a match only for Vnom. Change-Id: Ic8455cbd5a00dcc30e4989aa9db9b18c9da9741c Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
* OMAP3+: VP/VC: ensure vp errgen is configured for the right OPPNishanth Menon2012-05-104-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Since target_volt converted by omap_voltage_get_voltdata to get to vp_errgain for the OPP voltage level, we can have a scenario as follows: OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) vp_errgain=0x16 OPPNitro Vnom=1.375, Vcalib = 1.2V vp_errgain=0x27 When a request to vc_bypass or vp_forceupdate is provided to OPPNitro volt_data pointer, it in turn calls vc_prescale with 1.2V, this gets passed down to vp_errgen_configure, who converts it back into vdata using omap_voltage_get_voltdata However, omap_voltage_get_voltdata walks through the volt_data array and finds the first match of OPP100 where Vnom = 1.2V and returns the volt_data pointer for OPP100, this causes 0x16 to be selected for VP errgain instead of 0x27, causing instability for voltage scale operation. Instead, pass the volt_data pointer straight to vc_prescale and down to vp_errgen_configure to ensure that the right configuration parameters are used. Change-Id: I96c697175fb5d16c53de9891ec5c008101c0550b Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
* OMAP3+: LDO: ensure that right ABB type is selectedNishanth Menon2012-05-103-19/+15
| | | | | | | | | | | | | | | | | | | | | | | | | since target_volt converted by omap_voltage_get_voltdata to get to abb type for the OPP voltage level, we can have a scenario as follows: OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) ABB type - bypass OPPNitro Vnom=1.375, Vcalib = 1.2V ABB type = FBB in this case, voltdm_scale will first gets the operational_voltage of oppNitro and recieves 1.2V, sends it down to abb_prescale function which in turn converts it back into vdata using omap_voltage_get_voltdata however, omap_voltage_get_voltdata walks through the volt_data array and finds the first match of OPP100 where Vnom = 1.2V and returns the volt_data pointer for OPP100, this causes ABB logic to think that it is attempting to go to an OPP with bypass, which in effect crashes the device once frequency is set to OPPNitro, but ABB is in bypass mode. To solve this, we should pass the exact volt_data pointer down to the abb prescale and postscale handlers so that this back and forth conversion error does not take place. Change-Id: I49099caba069798d7bd8888c614fd5e2e27fab6f Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
* OMAP3630+: PM: LDO: ABB: ensure transition completeNishanth Menon2012-05-101-1/+35
| | | | | | | | | | | | | | | | | | | | | | Currently when we configure ABB LDO, we do the following: clear interrupt status program new ABB clear interrupt status This does not guarentee that the ABB LDO has achieved the desired configuration, and in cases where we are moving to high performance OPP such as OPP NitroSB, this could result in undeterministic failures on few corner lots. Fix to ensure the right sequence as: clear interrupt status program new ABB wait for interrupt clear interrupt status (even if wait failed.) Change-Id: Ida9320b9249a134f0ae33adf20ec2be81c806682 Reported-by: Vincent Bour <v-bour@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP3+: PM: VP: fix integer truncation errorYuan Jiangli2012-05-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the hardware translation of what the slew rate on the PMIC is. As an example, with TPS62361 on OMAP4460, step_size = 10000 slew_rate = 32000 sys_clk_rate = 38400 Our current computation of this results in the following: = ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((10000 / 32000) * 38400 / 1000 = 0 Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to: = (10000 * 38400) / (1000 * 32000) = 12 Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6 Acked-by: Jon Hunter <jon-hunter@ti.com> [nm@ti.com: slightly better implementation] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
* OMAP3+: PM: DVFS: decide to scale dependent domains based on nominal voltageNishanth Menon2012-05-102-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current DVFS scale decision assumes voltage dependency - hence the scale decision is implemented based on voltage transition decision. This is wrong as the dependency between domains is at OPP tuple level, so no matter what the voltage level is, if we transition from a lower frequency to a higher frequency, we should scale dependent domain ahead of transitioning voltage/frequency for the current domain, and viceversa when switching to lower OPP. With Smartreflex AVS Class3 or Smartreflex AVS Class1.5, consider the following Scenario: The current OPP might be in Vnom (Vn) - if SR is disabled OR if SR has not yet made the first adjustment Vcurrent(Vc) - which can either be: Vsr_intermdiate(Vi) - if SR was interrupted in the middle of convergence Vsr(Vs) - if SR has completed adjustment. For all purposes Current OPP's Vn > Vc. However, when we consider the new OPP we are entering (assume for SR1.5, new OPP is not a calibrated opp in this discussion): Going down, we have the following cases: Case a) current_Vn > current_Vc > new_Vn Case b) current_Vn > new_Vn > current_Vc Going up, we could have: Case c) new_Vn > current_Vn > current_Vc OR we might even have a scenario case d) current_Vn > (current_Vc == new_Vn) Today's code compares current_Vc against new_Vn, and makes a decision when to scale dependent domain. This will work find in case (a) and case (c). However, in case (b), we scale dependent domain at the wrong time, in case of case (d), we dont even attempt to scale dependent domains!! This is wrong. since the comparable factor which closely represents the order of OPP is Vnom, the right thing to check for scaling dependent domains is Vnom. Hence use it instead. Change-Id: I93868743301e115fab8e33ff14317b07b81ef5d8 Signed-off-by: Nishanth Menon <nm@ti.com>
* OMAP3+: PM: DVFS: fix making wrong scale direction decisionNishanth Menon2012-05-101-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most cases with SmartReflex AVS class 3 and Class 1.5 calibration, the SR adjusted voltage(Vsr) is usually lower than Vnom, However, at times, the Vsr for a higher OPP may even be lower than a couple of lower OPPs. For example, on a specific sample silicon on OMAP4430: MPU OPP Vsr Vnom OPP50 0.862249970436096 1.025 OPP100 1.03509700298309 1.2 OPPTurbo 1.09257805347443 1.325 OPPNitro 1.18703103065491 1.388 OPPNitroSB 1.29427194595337 1.398 Consider in the above case where we transition from OPPTurbo to OPP100 We are attempting to transition from 1.325V to 1.09V, if we pickup voltage while SmartReflex AVS convergence is taking place, we might pickup 1.21V which in effect is a scale down decision flag for DVFS. however, since SR was active, it could make a jump of upto 8steps (100mV) lowering the voltage to 1.1V after s/w sampled the voltage, which in reality should have made SR to do a scale up operation. This wrong scale direction can result in either dependent domain scale combination to be performed wrongly OR even scale with lower voltage for a given transition frequency resulting in device instability. Fix the same by sampling the voltage only after stopping SmartReflex AVS convergence. Change-Id: I119a22b7060f30d123c4fe3bcabfadb6d7d71419 Signed-off-by: Nishanth Menon <nm@ti.com>
* gpu: pvr: Update to DDK 1.8@904153Alistair Strachan2012-05-1013-458/+1213
| | | | | | | | | | | - Fix http://b/6446135 "eglHibernateProcessIMG slows down.." Release the bridge mutex in various places while waiting on the hardware. Permits multiple userspace processes/threads entering the driver simulataneously in some controlled cases. - Fix http://b/6096575 "some gralloc operations are very slow" Add a shrinkable pool for uncached memory allocations. Change-Id: I9c793ae3fae7b33f7b7c64aec53f848fed8d4eac
* OMAP4: MUSB: peripheral isoch IN endpt supportRuchika Kharwar2012-05-082-16/+36
| | | | | | | | | | | | | | | This patch does the following 1. Updation of the TXCSR programmation sequence 2. When the occurance of a DMA completion occurs, if the completion results in residual (< max_packet_sz) data the TXPKTRDY bit is set to allow the sending of this data. 3. The above could occur in 2 scenarios: a. DMA Mode 0 which requires as per specification to set TXPKTRDY and await the endpoint interrupt. b. DMA Mode 1, where the last packet is shorter that max_packet_sz. Change-Id: Id517ea74f2b3f6f66ea768f0b505b4c059b27f55 Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
* Merge commit 'v3.0.31' into linux-omap-3.0Todd Poynor2012-05-0853-164/+584
|\
| * Linux 3.0.31Greg Kroah-Hartman2012-05-071-1/+1
| |
| * hfsplus: Fix potential buffer overflowsGreg Kroah-Hartman2012-05-072-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6f24f892871acc47b40dd594c63606a17c714f77 upstream. Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by: Timo Warns <warns@pre-sense.de> Acked-by: WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * sched: Fix nohz load accounting -- again!Peter Zijlstra2012-05-071-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c308b56b5398779cd3da0f62ab26b0453494c3d4 upstream. [ backported to 3.0 by Kerin Millar <kerframil@gmail.com>] Various people reported nohz load tracking still being wrecked, but Doug spotted the actual problem. We fold the nohz remainder in too soon, causing us to loose samples and under-account. So instead of playing catch-up up-front, always do a single load-fold with whatever state we encounter and only then fold the nohz remainder and play catch-up. Reported-by: Doug Smythies <dsmythies@telus.net> Reported-by: LesÅ=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl> Reported-by: Aman Gupta <aman@tmm1.net> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.org Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Kerin Millar <kerframil@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * wl1251: fix crash on remove due to leftover work itemGrazvydas Ignotas2012-05-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * wl1251: fix crash on remove due to premature kfreeGrazvydas Ignotas2012-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 328c32f0f85467af5a6c4c3289e168d9ad2555af upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * rtlwifi: Fix oops on unloadLarry Finger2012-05-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 44eb65cfd8da4b9c231238998729e858e963a980 upstream. Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: Dave Airlie <airlied@gmail.com> Tested-by: Dave Airlie <airlied@gmail.com> Signed-off-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>
| * mac80211: fix AP mode EAP tx for VLAN stationsFelix Fietkau2012-05-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 66f2c99af3d6f2d0aa1120884cf1c60613ef61c0 upstream. EAP frames for stations in an AP VLAN are sent on the main AP interface to avoid race conditions wrt. moving stations. For that to work properly, sta_info_get_bss must be used instead of sta_info_get when sending EAP packets. Previously this was only done for cooked monitor injected packets, so this patch adds a check for tx->skb->protocol to the same place. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * ipw2200: Fix race condition in the command completion acknowledgeStanislav Yakovlev2012-05-071-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit dd447319895d0c0af423e483d9b63f84f3f8869a upstream. Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * i2c: pnx: Disable clk in suspendRoland Stigge2012-05-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6c557cfee08751d22aed34840f389b846f0f4508 upstream. In the driver's suspend function, clk_enable() was used instead of clk_disable(). This is corrected with this patch. Signed-off-by: Roland Stigge <stigge@antcom.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> [wsa: reworded commit header slightly] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * libata: skip old error history when counting probe trialsLin Ming2012-05-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6868225e3e92399068be9a5f1635752d91012ad5 upstream. Commit d902747("[libata] Add ATA transport class") introduced ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared. But ata_count_probe_trials_cb() didn't check this flag and it still counts the old error history. So wrong probe trials count is returned and it causes problem, for example, SATA link speed is slowed down from 3.0Gbps to 1.5Gbps. Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb(). Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * hwmon: (coretemp) fix oops on cpu unplugKirill A. Shutemov2012-05-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b704871124b477807966f06789c2b32f2de58bf7 upstream. coretemp tries to access core_data array beyond bounds on cpu unplug if core id of the cpu if more than NUM_REAL_CORES-1. BUG: unable to handle kernel NULL pointer dereference at 000000000000013c IP: [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] PGD 673e5a067 PUD 66e9b3067 PMD 0 Oops: 0000 [#1] SMP CPU 79 Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile] Pid: 3315, comm: set-cpus Tainted: G W 3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffffa00159af>] [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP: 0018:ffff880472fb3d48 EFLAGS: 00010246 RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001 R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800 R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000 FS: 00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000) Stack: ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005 0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14 ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034 Call Trace: [<ffffffff8161f48d>] notifier_call_chain+0x4d/0x70 [<ffffffff8107f1be>] __raw_notifier_call_chain+0xe/0x10 [<ffffffff81059d30>] __cpu_notify+0x20/0x40 [<ffffffff815fa251>] _cpu_down+0x81/0x270 [<ffffffff815fa477>] cpu_down+0x37/0x50 [<ffffffff815fd6a3>] store_online+0x63/0xc0 [<ffffffff813c7078>] dev_attr_store+0x18/0x30 [<ffffffff811f02cf>] sysfs_write_file+0xef/0x170 [<ffffffff81180443>] vfs_write+0xb3/0x180 [<ffffffff8118076a>] sys_write+0x4a/0x90 [<ffffffff816236a9>] system_call_fastpath+0x16/0x1b Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28 RIP [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP <ffff880472fb3d48> CR2: 000000000000013c Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * hwmon: (coretemp) Increase CPU core limitGuenter Roeck2012-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit bdc71c9a87b898e4c380c23b2e3e18071312ecde upstream. CPU core ID is used to index the core_data[] array. The core ID is, however, not sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to 32 to be able to deal with current CPUs. Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Acked-by: Jean Delvare <khali@linux-fr.org> Acked-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * efivars: Improve variable validationMatthew Garrett2012-05-071-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 54b3a4d311c98ad94b737802a8b5f2c8c6bfd627 upstream. Ben Hutchings pointed out that the validation in efivars was inadequate - most obviously, an entry with size 0 would server as a DoS against the kernel. Improve this based on his suggestions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * efi: Validate UEFI boot variablesMatthew Garrett2012-05-071-0/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fec6c20b570bcf541e581fc97f2e0cbdb9725b98 upstream. A common flaw in UEFI systems is a refusal to POST triggered by a malformed boot variable. Once in this state, machines may only be restored by reflashing their firmware with an external hardware device. While this is obviously a firmware bug, the serious nature of the outcome suggests that operating systems should filter their variable writes in order to prevent a malicious user from rendering the machine unusable. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * efivars: fix warnings when CONFIG_PSTORE=nTony Luck2012-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b728a5c806fb36f9adebf2a862bbd015e074afca upstream. drivers/firmware/efivars.c:161: warning: ‘utf16_strlen’ defined but not used utf16_strlen() is only used inside CONFIG_PSTORE - make this "static inline" to shut the compiler up [thanks to hpa for the suggestion]. drivers/firmware/efivars.c:602: warning: initialization from incompatible pointer type Between v1 and v2 of this patch series we decided to make the "part" number unsigned - but missed fixing the stub version of efi_pstore_write() Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com> [took the static part of the patch, not the pstore part, for 3.0-stable, to fix the compiler warning we had - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * efivars: String functionsMike Waychison2012-05-071-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a2940908391f3cee72e38769b30e829b22742b5b upstream. Fix the string functions in the efivars driver to be called utf16_* instead of utf8_* as the encoding is utf16, not utf8. As well, rename utf16_strlen to utf16_strnlen as it takes a maxlength argument and the name should be consistent with the standard C function names. utf16_strlen is still provided for convenience in a subsequent patch. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * efi: Add new variable attributesMatthew Garrett2012-05-071-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream. More recent versions of the UEFI spec have added new attributes for variables. Add them. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * SCSI: libsas: fix false positive 'device attached' conditionsDan Williams2012-05-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7d1d865181185bdf1316d236b1b4bd02c9020729 upstream. Normalize phy->attached_sas_addr to return a zero-address in the case when device-type == NO_DEVICE or the linkrate is invalid to handle expanders that put non-zero sas addresses in the discovery response: sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device) Reported-by: Andrzej Jakowski <andrzej.jakowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * SCSI: libsas: fix sas_find_bcast_phy() in the presence of 'vacant' physThomas Jackson2012-05-071-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1699490db339e2c6b3037ea8e7dcd6b2755b688e upstream. If an expander reports 'PHY VACANT' for a phy index prior to the one that generated a BCN libsas fails rediscovery. Since a vacant phy is defined as a valid phy index that will never have an attached device just continue the search. Signed-off-by: Thomas Jackson <thomas.p.jackson@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * ARM: 7403/1: tls: remove covert channel via TPIDRURWWill Deacon2012-05-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream. TPIDRURW is a user read/write register forming part of the group of thread registers in more recent versions of the ARM architecture (~v6+). Currently, the kernel does not touch this register, which allows tasks to communicate covertly by reading and writing to the register without context-switching affecting its contents. This patch clears TPIDRURW when TPIDRURO is updated via the set_tls macro, which is called directly from __switch_to. Since the current behaviour makes the register useless to userspace as far as thread pointers are concerned, simply clearing the register (rather than saving and restoring it) will not cause any problems to userspace. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * autofs: make the autofsv5 packet file descriptor use a packetized pipeLinus Torvalds2012-05-073-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 64f371bc3107e69efce563a3d0f0e6880de0d537 upstream. The autofs packet size has had a very unfortunate size problem on x86: because the alignment of 'u64' differs in 32-bit and 64-bit modes, and because the packet data was not 8-byte aligned, the size of the autofsv5 packet structure differed between 32-bit and 64-bit modes despite looking otherwise identical (300 vs 304 bytes respectively). We first fixed that up by making the 64-bit compat mode know about this problem in commit a32744d4abae ("autofs: work around unhappy compat problem on x86-64"), and that made a 32-bit 'systemd' work happily on a 64-bit kernel because everything then worked the same way as on a 32-bit kernel. But it turned out that 'automount' had actually known and worked around this problem in user space, so fixing the kernel to do the proper 32-bit compatibility handling actually *broke* 32-bit automount on a 64-bit kernel, because it knew that the packet sizes were wrong and expected those incorrect sizes. As a result, we ended up reverting that compatibility mode fix, and thus breaking systemd again, in commit fcbf94b9dedd. With both automount and systemd doing a single read() system call, and verifying that they get *exactly* the size they expect but using different sizes, it seemed that fixing one of them inevitably seemed to break the other. At one point, a patch I seriously considered applying from Michael Tokarev did a "strcmp()" to see if it was automount that was doing the operation. Ugly, ugly. However, a prettier solution exists now thanks to the packetized pipe mode. By marking the communication pipe as being packetized (by simply setting the O_DIRECT flag), we can always just write the bigger packet size, and if user-space does a smaller read, it will just get that partial end result and the extra alignment padding will simply be thrown away. This makes both automount and systemd happy, since they now get the size they asked for, and the kernel side of autofs simply no longer needs to care - it could pad out the packet arbitrarily. Of course, if there is some *other* user of autofs (please, please, please tell me it ain't so - and we haven't heard of any) that tries to read the packets with multiple writes, that other user will now be broken - the whole point of the packetized mode is that one system call gets exactly one packet, and you cannot read a packet in pieces. Tested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Miller <davem@davemloft.net> Cc: Ian Kent <raven@themaw.net> Cc: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * pipes: add a "packetized pipe" mode for writingLinus Torvalds2012-05-072-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9883035ae7edef3ec62ad215611cb8e17d6a1a5d upstream. The actual internal pipe implementation is already really about individual packets (called "pipe buffers"), and this simply exposes that as a special packetized mode. When we are in the packetized mode (marked by O_DIRECT as suggested by Alan Cox), a write() on a pipe will not merge the new data with previous writes, so each write will get a pipe buffer of its own. The pipe buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn will tell the reader side to break the read at that boundary (and throw away any partial packet contents that do not fit in the read buffer). End result: as long as you do writes less than PIPE_BUF in size (so that the pipe doesn't have to split them up), you can now treat the pipe as a packet interface, where each read() system call will read one packet at a time. You can just use a sufficiently big read buffer (PIPE_BUF is sufficient, since bigger than that doesn't guarantee atomicity anyway), and the return value of the read() will naturally give you the size of the packet. NOTE! We do not support zero-sized packets, and zero-sized reads and writes to a pipe continue to be no-ops. Also note that big packets will currently be split at write time, but that the size at which that happens is not really specified (except that it's bigger than PIPE_BUF). Currently that limit is the system page size, but we might want to explicitly support bigger packets some day. The main user for this is going to be the autofs packet interface, allowing us to stop having to care so deeply about exact packet sizes (which have had bugs with 32/64-bit compatibility modes). But user space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will fail with an EINVAL on kernels that do not support this interface. Tested-by: Michael Tokarev <mjt@tls.msk.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Miller <davem@davemloft.net> Cc: Ian Kent <raven@themaw.net> Cc: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb gadget: uvc: uvc_request_data::length field must be signedLaurent Pinchart2012-05-072-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 6f6543f53f9ce136e01d7114bf6f0818ca54fb41 upstream. The field is used to pass the UVC request data length, but can also be used to signal an error when setting it to a negative value. Switch from unsigned int to __s32. Reported-by: Fernandez Gonzalo <gfernandez@copreci.es> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.1 at 2025-02-03 19:46:33 +0000