linux/drivers, branch v3.7

Input: matrix-keymap - provide proper module license

2012-12-11T00:10:05Z

The matrix-keymap module is currently lacking a proper module license, add one so we don't have this module tainting the entire kernel. This issue has been present since commit 1932811f426f ("Input: matrix-keymap - uninline and prepare for device tree support") Signed-off-by: Florian Fainelli CC: stable@vger.kernel.org # v3.5+ Signed-off-by: Dmitry Torokhov Signed-off-by: Linus Torvalds

Revert "revert "Revert "mm: remove __GFP_NO_KSWAPD""" and associated damage

2012-12-10T19:03:05Z

This reverts commits a50915394f1fc02c2861d3b7ce7014788aa5066e and d7c3b937bdf45f0b844400b7bf6fd3ed50bac604. This is a revert of a revert of a revert. In addition, it reverts the even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the original commits in linux-next. It turns out that the original patch really was bogus, and that the original revert was the correct thing to do after all. We thought we had fixed the problem, and then reverted the revert, but the problem really is fundamental: waking up kswapd simply isn't the right thing to do, and direct reclaim sometimes simply _is_ the right thing to do. When certain allocations fail, we simply should try some direct reclaim, and if that fails, fail the allocation. That's the right thing to do for THP allocations, which can easily fail, and the GPU allocations want to do that too. So starting kswapd is sometimes simply wrong, and removing the flag that said "don't start kswapd" was a mistake. Let's hope we never revisit this mistake again - and certainly not this many times ;) Acked-by: Mel Gorman Acked-by: Johannes Weiner Cc: Rik van Riel Cc: Andrew Morton Signed-off-by: Linus Torvalds

Merge tag 'mmc-fixes-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc

2012-12-07T17:15:20Z

Pull MMC fixes from Chris Ball: "Two small regression fixes: - sdhci-s3c: Fix runtime PM regression against 3.7-rc1 - sh-mmcif: Fix oops against 3.6" * tag 'mmc-fixes-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: mmc: sh-mmcif: avoid oops on spurious interrupts (second try) Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts" mmc: sdhci-s3c: fix missing clock for gpio card-detect

mmc: sh-mmcif: avoid oops on spurious interrupts (second try)

2012-12-06T18:54:35Z

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious interrupts without any active request. To prevent the Oops, that results in such cases, don't dereference the mmc request pointer until we make sure, that we are indeed processing such a request. Reported-by: Tetsuyuki Kobayashi Signed-off-by: Guennadi Liakhovetski Tested-by: Tetsuyuki Kobayashi Cc: stable@vger.kernel.org Signed-off-by: Chris Ball

Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"

2012-12-06T18:54:34Z

This reverts commit 8464dd52d3198dd05, which was a misapplied debugging version of the patch, not the final patch itself. Signed-off-by: Chris Ball Cc: stable@vger.kernel.org

mmc: sdhci-s3c: fix missing clock for gpio card-detect

2012-12-06T18:54:33Z

2abeb5c5ded2 ("Add clk_(enable/disable) in runtime suspend/resume") added the capability to stop the clocks when the device is runtime suspended, but forgot to handle the case of the card-detect using an external gpio. Therefore in the case that runtime-pm is enabled, start the io-clock when a card is inserted and stop it again once it is removed. Signed-off-by: Heiko Stuebner Signed-off-by: Chris Ball

Merge tag 'upstream-3.7-rc9' of git://git.infradead.org/linux-ubi

2012-12-04T17:15:51Z

Pull UBI changes from Artem Bityutskiy: "Fixes for 2 brown-paperbag bugs introduced this merge window by the fastmap code: 1. The UBI background thread got stuck when a bit-flip happened because free LEBs was not removed from the "free" tree when we started using it. 2. I/O debugging checks did not work because we called a sleeping function in atomic context." * tag 'upstream-3.7-rc9' of git://git.infradead.org/linux-ubi: UBI: dont call ubi_self_check_all_ff() in __wl_get_peb() UBI: remove PEB from free tree in get_peb_for_wl()

Merge branch 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2012-12-04T17:02:45Z

Pull workqueue fixes from Tejun Heo: "So, safe fixes my ass. Commit 8852aac25e79 ("workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay") had the side-effect of performing delayed_work sanity checks even when @delay is 0, which should be fine for any sane use cases. Unfortunately, megaraid was being overly ingenious. It seemingly wanted to use cancel_delayed_work_sync() before cancel_work_sync() was introduced, but didn't want to waste the space for full delayed_work as it was only going to use 0 @delay. So, it only allocated space for struct work_struct and then cast it to struct delayed_work and passed it into delayed_work functions - truly awesome engineering tradeoff to save some bytes. Xiaotian fixed it by making megraid allocate full delayed_work for now. It should be converted to use work_struct and cancel_work_sync() but I think we better do that after 3.7. I added another commit to change BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s so that the kernel doesn't crash even if there are more such abuses." * 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s megaraid: fix BUG_ON() from incorrect use of delayed work

megaraid: fix BUG_ON() from incorrect use of delayed work

2012-12-04T15:29:47Z

megaraid use INIT_WORK to declare a hotplug_work, but cast the hotplug_work from work_struct to delayed_work and schedule_delayed_work on it. This is very dangerous, as other part of delayed_work might be kernel memories allocated by others. With commit 8852aac ("workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay"), schedule_delayed_work() will check dwork->timer before queue_work even when @delay is 0, this causes megaraid code to hit the BUG_ON() in workqueue code. Change megaraid code to use delayed work. Signed-off-by: Xiaotian Feng Signed-off-by: Tejun Heo Cc: Neela Syam Kolli Cc: "James E.J. Bottomley" Cc: linux-scsi@vger.kernel.org

UBI: dont call ubi_self_check_all_ff() in __wl_get_peb()

2012-12-04T14:04:31Z

As ubi_self_check_all_ff() might sleep we are not allowed to call it from atomic context. For now we call it only from ubi_wl_get_peb(). There are some code paths where it would also make sense, but these paths are currently atomic and only enabled when fastmap is used. Signed-off-by: Richard Weinberger Signed-off-by: Artem Bityutskiy