path: root/drivers
AgeCommit message (Collapse)Author
2011-05-16OMAP4: DSS2: HDMI: Add enums and structures for audioRicardo Neri
Add enurations and structures for audio configuration. This includes enumerations for the Audio InfoFrame, I2S, audio FIFO and audio core. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
2011-05-16OMAPFB: re-allocate FB if needed on resize notificationSebastien Jan
Note that re-allocating can fragment vram, so to avoid re-allocation, pre-assign FB size with kernel bootargs like: omapfb.vram=0:8M,1:8M Note: prevent the console accessing the FB while re-allocation is running. Other early FB users would be an issue as well. Signed-off-by: Sebastien Jan <s-jan@ti.com>
2011-05-16OMAP: DSS2: DSI: Introduce sync_vc functionsArchit Taneja
The DSI protocol engine has no interrupt for signalling the end of a Frame transfer. The present approach is to send a BTA after DISPC generates a FRAMEDONE interrupt, and unlock the dsi bus only when the BTA Ack is received. The assumption made with this approach was that OMAP will send a BTA only after the long packet corresponding to the last line is sent. However, it is possible that on the DISPC FRAMEDONE interrupt there are 2 (or more) lines of pixel data in the DSI line buffer. Hence, the BTA Ack could be received for the long packet corresponding to the second last line (or the third last and so on..). Therefore, the current method doesn't ensure that the complete frame data is sent before we start a new transfer. A similar explanation holds valid if we send a BTA in between multiple short/long command packets from the slave port. Introduce dsi_sync_vc functions, based on Tomi Valkeinen's idea, which ensure that the DSI Virtual Channel in use(update_channel) completes its previous work before proceeding to the next Frame/Command. For a frame update, the DSI driver now sends a callback to the Panel Driver on the FRAMEDONE interrupt itself. The callback in the panel driver then unlocks the bus. dsi_sync_vc() functions are placed in dsi_vc_config_l4() and dsi_vc_config_vp() to ensure that the previous task of the Virtual Channel is completed. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16DSS: fix DVI and DSI concurrent supportSebastien Jan
DSI requires the OMAP2_DSS_USE_DSI_PLL flag to work, and the dummy regulators. The USE_DSI_PLL flag also impacts DPI (for DVI on pandaboard), and currently breaks it. So deactivate the USE_DSI_PLL flag and hack DSI code to enable DSI support. Signed-off-by: Sebastien Jan <s-jan@ti.com>
2011-05-16OMAP4: OMAPFB: register callback to get notified of resolution changeSebastien Jan
Protect fb_set_var() with console-sem to avoid making console driver unhappy. Supports more than one framebuffer. This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Sebastien Jan <s-jan@ti.com>
2011-05-16OMAP4: DSS: add generic notifier mechanismSebastien Jan
A callback can be registered by the dssdev client in order to be notified of resolution changes, for example an external monitor that is hot-plugged. Multiple clients can now register for notification from one dssdev, and the notification mechanism can be extended in the future to add other events. This is a port of Rob Clark's <rob@ti.com> original patch. Signed-off-by: Sebastien Jan <s-jan@ti.com>
2011-05-16v4l2: omap: pass debug param to v4l2 frameworkSebastien Jan
The omap_vout debug module parameter can be passed to the v4l2 framework. For this, its type has to be extended. Signed-off-by: Sebastien Jan <s-jan@ti.com>
2011-05-16OMAP: DSS2: Adding macro for DISPC_DIVISOR registerRaghuveer Murthy
Added macro for DISPC_DIVISOR. This is different from DISPC_DIVISOR1 and DISPC_DIVISOR2. OMAP4 supports all the above 3 registers. DISPC_DIVISOR1 and DISPC_DIVISOR2 registers are accessed through DISPC_DIVISORo(ch) macro Signed-off-by: Raghuveer Murthy <raghuveer.murthy@ti.com>
2011-05-16OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driverSenthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for DSI is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers. Also, vdds_dsi regulator handling is copied to dsi.c, since vdds_dsi regulator is needed by dpi_init() too. Board files are updated accordingly to add 2 instances of vdds_dsi regulator. DSI platform driver is registered from inside omap_dss_probe, in the order desired. Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driverSenthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver. So a platform_driver for VENC is created and init exit methods are moved from core.c to its driver probe,remove. pdev member has to be maintained by its own drivers. Also, venc_vdda_dac reading is moved to venc.c. VENC platform driver is registered from inside omap_dss_probe, in the order desired. Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16V4L2: OMAP: Make it work for OMAP4Jassi Brar
Some logical optimization and redundat checks removed. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2011-05-16mmc: omap: Fix possible NULL pointer derefMichael Buesch
Either OMAP_MMC_STAT_CARD_ERR or OMAP_MMC_STAT_END_OF_CMD might fire if there is no host->cmd pointer. Check for a valid host->cmd pointer before calling mmc_omap_cmd_done(). Signed-off-by: Michael Buesch <mb@bu3sch.de> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Chris Ball <cjb@laptop.org> (cherry picked from commit f69475142136c8ad9b9c717aea2ff907aed9f863)
2011-05-16smsc95xx: fix reset checkRabin Vincent
The reset loop check should check the MII_BMCR register value for BMCR_RESET rather than for MII_BMCR (the register address, which also happens to be zero). Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit d946092000698fd204d82a9d239103c656fb63bf)
2011-05-16Merge commit 'v2.6.38.6' into linaro-2.6.38Nicolas Pitre
2011-05-09fix oops in scsi_run_queue()James Bottomley
commit c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream. The recent commit closing the race window in device teardown: commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b Author: James Bottomley <James.Bottomley@suse.de> Date: Fri Apr 22 10:39:59 2011 -0500 [SCSI] put stricter guards on queue dead checks is causing a potential NULL deref in scsi_run_queue() because the q->queuedata may already be NULL by the time this function is called. Since we shouldn't be running a queue that is being torn down, simply add a NULL check in scsi_run_queue() to forestall this. Tested-by: Jim Schutt <jaschut@sandia.gov> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09cx88: Fix HVR4000 IR keymapLawrence Rust
[fixed in .39 in a much different way that is too big to backport to .38 - gregkh] Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in the 2.6.38 kernel. Signed-off-by: Lawrence Rust <lvr@softsystem.dot.uk> Acked-by: Jarod Wilson <jarod@wilsonet.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-05-09ath9k: fix the return value of ath_stoprecvFelix Fietkau
commit 2232d31bf18ba02f5cd632bbfc3466aeca394c75 upstream. The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect a condition where rx DMA was stopped, but the MAC failed to enter the idle state. This condition requires a hardware reset, however the return value of ath_stoprecv was 'true' in that case, which allowed it to skip the reset when issuing a fast channel change. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Reported-by: Paul Stewart <pstew@google.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09imon: add conditional locking in change_protocolJarod Wilson
commit 23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e upstream. The imon_ir_change_protocol function gets called two different ways, one way is from rc_register_device, for initial protocol selection/setup, and the other is via a userspace-initiated protocol change request, either by direct sysfs prodding or by something like ir-keytable. In the rc_register_device case, the imon context lock is already held, but when initiated from userspace, it is not, so we must acquire it, prior to calling send_packet, which requires that the lock is held. Without this change, there's an easily reproduceable deadlock when another function calls send_packet (such as either of the display write fops) after a userspace-initiated change_protocol. With a lock-debugging-enabled kernel, I was getting this: [ 15.014153] ===================================== [ 15.015048] [ BUG: bad unlock balance detected! ] [ 15.015048] ------------------------------------- [ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at: [ 15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10 [ 15.015048] but there are no more locks to release! [ 15.015048] [ 15.015048] other info that might help us debug this: [ 15.015048] 2 locks held by ir-keytable/773: [ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144 [ 15.015048] #1: (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144 [ 15.015048] [ 15.015048] stack backtrace: [ 15.015048] Pid: 773, comm: ir-keytable Not tainted #1 [ 15.015048] Call Trace: [ 15.015048] [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5 [ 15.015048] [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4 [ 15.015048] [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon] [ 15.015048] [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263 [ 15.015048] [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon] [ 15.015048] [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core] [ 15.015048] [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22 [ 15.015048] [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144 ... The original report that led to the investigation was the following: [ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds. [ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1679.457309] LCDd D ffff88010fcd89c8 0 8460 1 0x00000000 [ 1679.457312] ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8 [ 1679.457314] 00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0 [ 1679.457316] ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8 [ 1679.457319] Call Trace: [ 1679.457324] [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90 [ 1679.457327] [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820 [ 1679.457330] [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320 [ 1679.457335] [<ffffffff813b0c41>] mutex_lock+0x11/0x30 [ 1679.457338] [<ffffffffa0d54216>] display_open+0x66/0x130 [imon] [ 1679.457345] [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore] [ 1679.457349] [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0 [ 1679.457350] [<ffffffff8113d93d>] __dentry_open+0x10d/0x370 [ 1679.457352] [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0 ... Bump the driver version here so its easier to tell if people have this locking fix or not, and also make locking during probe easier to follow. Reported-by: Benjamin Hodgetts <ben@xnode.org> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09v4l: make sure drivers supply a zeroed struct v4l2_subdevHerton Ronaldo Krzesinski
commit 80845a33165278f3236812009e9c568ba8c29938 upstream. Some v4l drivers currently don't initialize their struct v4l2_subdev with zeros, and this is a problem since some of the v4l2 code expects this. One example is the addition of internal_ops in commit 45f6f84, after that we are at risk of random oopses with these drivers when code in v4l2_device_register_subdev tries to dereference sd->internal_ops->*, as can be shown by the report at http://bugs.launchpad.net/bugs/745213 and analysis of its crash at https://lkml.org/lkml/2011/4/1/168 Use kzalloc within problematic drivers to ensure we have a zeroed struct v4l2_subdev. BugLink: http://bugs.launchpad.net/bugs/745213 Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09usbnet: add support for some Huawei modems with cdc-ether portsDan Williams
commit b3c914aa84f4e4bbb3efc8f41c359d96e5e932d2 upstream. Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether compatible ports, so recognize and expose them. Signed-off-by: Dan Williams <dcbw@redhat.com> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09firewire: Fix for broken configrom updates in quick successionB.J. Buchalter
commit 2e053a27d9d5ad5e0831e002cbf8043836fb2060 upstream. Current implementation of ohci_set_config_rom() uses a deferred bus reset via fw_schedule_bus_reset(). If clients add multiple unit descriptors to the config_rom in quick succession, the deferred bus reset may not have fired before succeeding update requests have come in. This can lead to an incorrect partial update of the config_rom for both addition and removal of config_rom descriptors, as the ohci_set_config_rom() routine will return -EBUSY if a previous pending update has not been completed yet; the requested update just gets dropped on the floor. This patch recognizes that the "in-flight" update can be modified until it has been processed by the bus-reset, and the locking in the bus_reset_tasklet ensures that the update is done atomically with respect to modifications made by ohci_set_config_rom(). The -EBUSY error case is simply removed. [Stefan R: The bug always existed at least theoretically. But it became easy to trigger since 2.6.36 commit 02d37bed188c "firewire: core: integrate software-forced bus resets with bus management" which introduced long mandatory delays between janitorial bus resets.] Signed-off-by: Benjamin Buchalter <bj@mhlabs.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09USB: fix regression in usbip by setting has_tt flagAlan Stern
commit cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream. This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09drm/radeon: fix regression on atom cards with hardcoded EDID record.Dave Airlie
commit eaa4f5e1d0b816291a59a47917e569c0384f2b6f upstream. Since fafcf94e2b5732d1e13b440291c53115d2b172e9 introduced an edid size, it seems to have broken this path. This manifest as oops on T500 Lenovo laptops with dual graphics primarily. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812 Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finishChris Ball
commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream. It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finishBen Dooks
commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream. It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()Chris Ball
commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream. If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09mmc: fix a race between card-detect rescan and clock-gate work instancesGuennadi Liakhovetski
commit 26fc8775b51484d8c0a671198639c6d5ae60533e upstream. Currently there is a race in the MMC core between a card-detect rescan work and the clock-gating work, scheduled from a command completion. Fix it by removing the dedicated clock-gating mutex and using the MMC standard locking mechanism instead. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Simon Horman <horms@verge.net.au> Cc: Magnus Damm <damm@opensource.se> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09atl1c: Fix work event interrupt/task racesTim Gardner
commit cb771838715b1c470bc5735bdae709b33b18e0ad upstream. The mechanism used to initiate work events from the interrupt handler has a classic read/modify/write race between the interrupt handler that sets the condition, and the worker task that reads and clears the condition. Close these races by using atomic bit fields. Cc: Jie Yang <jie.yang@atheros.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09iwlagn: fix "Received BA when not expected"Stanislaw Gruszka
commit bfd36103ec26599557c2bd3225a1f1c9267f8fcb upstream. Need to use broadcast sta_id for management frames, otherwise we broke BA session in the firmware and get messages like that: "Received BA when not expected" or (on older kernels): "BA scd_flow 0 does not match txq_id 10" This fix regression introduced in 2.6.35 during station management code rewrite by: commit 2a87c26bbe9587baeb9e56d3ce0b4971bd777643 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Apr 30 11:30:45 2010 -0700 iwlwifi: use iwl_find_station less Patch partially resolve: https://bugzilla.kernel.org/show_bug.cgi?id=16691 However, there are still 11n performance problems on 4965 and 5xxx devices that need to be investigated. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09iwlwifi: fix skb usage after freeStanislaw Gruszka
commit b25026981aecde3685dd0e45ad980fff9f528daa upstream. Since commit a120e912eb51e347f36c71b60a1d13af74d30e83 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09i2c-parport: Fix adapter list handlingJean Delvare
commit 56acc7a39ac4ac7638cdc32cd3d0832ebbc834e4 upstream. Use a standard list with proper locking to handle the list of adapters. Thankfully it only matters on systems with more than one parallel port, which are very rare. Thanks to Lukasz Kapiec for reporting the problem to me. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09put stricter guards on queue dead checksJames Bottomley
commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream. SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way. Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09scsi_dh: fix reference counting in scsi_dh_activate error pathMike Snitzer
commit 0b8393578c70bc1f09790eeae7d918f38da2e010 upstream. Commit db422318cbca55168cf965f655471dbf8be82433 ([SCSI] scsi_dh: propagate SCSI device deletion) introduced a regression where the device reference is not dropped prior to scsi_dh_activate's early return from the error path. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09mpt2sas: prevent heap overflows and unchecked readsDan Rosenberg
commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 upstream. At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation. Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Acked-by: Eric Moore <eric.moore@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-09pmcraid: reject negative request sizeDan Rosenberg
commit 5f6279da3760ce48f478f2856aacebe0c59a39f3 upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. Not especially relevant from a security perspective, since users must have CAP_SYS_ADMIN to open the character device. First, the user can call pmcraid_chr_ioctl() with a type PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. Prevent this value from being negative in pmcraid_ioctl_passthrough(). Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: Anil Ravindranath <anil_ravindranath@pmc-sierra.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-05mmc: mmci: Add ARM variant with extended FIFOPawel Moll
New IO FPGA implementation for Versatile Express boards contain MMCI (PL180) cell with FIFO extended to 128 words (512 bytes). Matt Waddel reports that this patch improves MMC performance on his vexpress system, and also fixes "mmcblk0: error -5 transferring data" errors. Signed-off-by: Pawel Moll <pawel.moll@arm.com> Tested-by: Matt Waddel <matt.waddel@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org> (cherry picked from commit 768fbc1876b3239f4c463c00ea1e78725554cf21)
2011-05-02Merge commit 'v2.6.38.5' into linaro-2.6.38Nicolas Pitre
2011-05-02Input: xen-kbdfront - fix mouse getting stuck after save/restoreIgor Mammedov
commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream. Mouse gets "stuck" after restore of PV guest but buttons are in working condition. If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space. Regression was introduced by hunk 5 and 6 of 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db ("Input: xen-kbdfront - advertise either absolute or relative coordinates"). Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254. Acked-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> [v1: Expanded the commit description] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2011-05-02iwlegacy: fix tx_power initializationStanislaw Gruszka
commit 332704a51498a7e29aa92c19dc03f11f80b71bfe upstream. priv->tx_power_next is not initialized to max supported power, but instead default value is used, what cause errors like [ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14. [ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22). if maximum tx power read from the eeprom is smaller than default. In consequence card is unable to initialize properly. Fix the problem and cleanup tx power initialization. Reported-and-tested-by: Robin Dong <hao.bigrat@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02iwl3945: disable hw scan by defaultStanislaw Gruszka
commit 0263aa45293838b514b8af674a03faf040991a90 upstream. After new NetworkManager 0.8.996 changes, hardware scanning is causing microcode errors as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=683571 and sometimes kernel crashes: https://bugzilla.redhat.com/show_bug.cgi?id=688252 Also with hw scan there are very bad performance on some systems as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=671366 Since Intel no longer supports 3945, there is no chance to get proper firmware fixes, we need workaround problems by disable hardware scanning by default. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02iwl3945: do not deprecate software scanStanislaw Gruszka
commit 3bda50e3eaf58a4b9c4ce34204e5faa15c8b1b97 upstream. Software scanning can be used for workaround some performance problems, so do not deprecate it. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02iwlwifi: do not set tx power when channel is changingStanislaw Gruszka
commit f844a709a7d8f8be61a571afc31dfaca9e779621 upstream. Mac80211 can request for tx power and channel change in one ->config call. If that happens, *_send_tx_power functions will try to setup tx power for old channel, what can be not correct because we already change the band. I.e error "Failed to get channel info for channel 140 [0]", can be printed frequently when operating in software scanning mode. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02agp: fix OOM and buffer overflowVasiliy Kulikov
commit b522f02184b413955f3bc952e3776ce41edc6355 upstream. page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02agp: fix arbitrary kernel memory writesVasiliy Kulikov
commit 194b3da873fd334ef183806db751473512af29ce upstream. pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLEDave Airlie
commit bf5192edcbc1f0a7f9c054649dbf1a0b3210d9b7 upstream. Multi-gpu/switcheroo relies on this option to get the console on the correct GPU at bootup, some distros enable it but it seems some get it wrong. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02virtio: console: Enable call to hvc_remove() on console port removeAmit Shah
commit afa2689e19073cd2e762d0f2c1358fab1ab9f18c upstream. This call was disabled as hot-unplugging one virtconsole port led to another virtconsole port freezing. Upon testing it again, this now works, so enable it. In addition, a bug was found in qemu wherein removing a port of one type caused the guest output from another port to stop working. I doubt it was just this bug that caused it (since disabling the hvc_remove() call did allow other ports to continue working), but since it's all solved now, we're fine with hot-unplugging of virtconsole ports. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pciPatrick Boettcher
commit b934c20de1398d4a82d2ecfeb588a214a910f13f upstream. This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good. This has been fixed in several attempts by several people, but obviously never made it into the kernel. Signed-off-by: Patrick Boettcher <pboettcher@kernellabs.com> Cc: Steffen Barszus <steffenbpunkt@googlemail.com> Cc: Boris Cuber <me@boris64.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02ACPI / PM: Avoid infinite recurrence while registering power resourcesRafael J. Wysocki
commit 7bed50c5edf5cba8dd515a31191cbfb6065ddc85 upstream. There is at least one BIOS with a DSDT containing a power resource object with a _PR0 entry pointing back to that power resource. In consequence, while registering that power resource acpi_bus_get_power_flags() sees that it depends on itself and tries to register it again, which leads to an infinitely deep recurrence. This problem was introduced by commit bf325f9538d8c89312be305b9779e (ACPI / PM: Register power resource devices as soon as they are needed). To fix this problem use the observation that power resources cannot be power manageable and prevent acpi_bus_get_power_flags() from being called for power resource objects. References: https://bugzilla.kernel.org/show_bug.cgi?id=31872 Reported-and-tested-by: Pascal Dormeau <pdormeau@free.fr> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Len Brown <lenb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02ath9k_hw: partially revert "fix dma descriptor rx error bit parsing"Felix Fietkau
commit 115dad7a7f42e68840392767323ceb9306dbdb36 upstream. The rx error bit parsing was changed to consider PHY errors and various decryption errors separately. While correct according to the documentation, this is causing spurious decryption error reports in some situations. Fix this by restoring the original order of the checks in those places, where the errors are meant to be mutually exclusive. If a CRC error is reported, then MIC failure and decryption errors are irrelevant, and a PHY error is unlikely. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-02ACPI battery: fribble sysfs files from a resume notifierKyle McMartin
commit 25be5821521640eb00b7eb219ffe59664510d073 upstream. Commit da8aeb92 re-poked the battery on resume, but Linus reports that it broke his eee and partially reverted it in b23fffd7. Unfortunately this also results in my x201s giving crack values until the sysfs files are poked again. In the revert message, it was suggested that we poke it from a PM notifier, so let's do that. With this in place, I haven't noticed the units going nutty on my gnome-power-manager across a dozen suspends or so... Signed-off-by: Kyle McMartin <kyle@redhat.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>