summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-03-25mac80211: fix remain-on-channel cancel crashJohannes Berg
If a ROC item is canceled just as it expires, the work struct may be scheduled while it is running (and waiting for the mutex). This results in it being run after being freed, which obviously crashes. To fix this don't free it when aborting is requested but instead mark it as "to be freed", which makes the work a no-op and allows freeing it outside. Cc: stable@vger.kernel.org [3.6+] Reported-by: Jouni Malinen <j@w1.fi> Tested-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-25Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm fixes from Dave Airlie: "Exynos and Intel fixes. The intel fixes are fairly straightforward, mostly reverts due to bugs found. The exynos one is a big larger since they found some issues with the G2D engine and iommu interaction, and needed to verify the operations a lot better than they were previously, otherwise a user app can just crash the kernel with an iommu fault." * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: Revert "drm/i915: write backlight harder" drm/i915: don't disable the power well yet Revert "drm/i915: set TRANSCODER_EDP even earlier" drm/exynos: Check g2d cmd list for g2d restrictions drm/exynos: Add a new function to get gem buffer size drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Clean up some G2D codes for readability drm/exynos: Fix G2D core malfunctioning issue drm/exynos: clear node object type at gem unmap drm/exynos: Fix error routine to getting dma addr. drm/exynos: Replaced kzalloc & memcpy with kmemdup drm/exynos: fimd: calculate the correct address offset drm/exynos: Make mixer_check_timing static drm/exynos: modify the compatible string for exynos fimd
2013-03-25xfrm: Fix esn sequence number diff calculation in xfrm_replay_notify_esn()Mathias Krause
Commit 0017c0b "xfrm: Fix replay notification for esn." is off by one for the sequence number wrapped case as UINT_MAX is 0xffffffff, not 0x100000000. ;) Just calculate the diff like done everywhere else in the file. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2013-03-25powerpc: make additional room in exception vector areaChen Gang
The FWNMI region is fixed at 0x7000 and the vector are now overflowing that with allmodconfig. Fix that by moving slb_miss_realmode code out of that region as it doesn't need to be that close to the call sites (it is a _GLOBAL function) Fixes this build error: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards Signed-off-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
2013-03-25Merge branch 'drm-intel-fixes' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into HEAD Daniel writes: "Just three revert/disable by default patches, one of them cc: stable (since the offending commit was cc: stable, too)." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: Revert "drm/i915: write backlight harder" drm/i915: don't disable the power well yet Revert "drm/i915: set TRANSCODER_EDP even earlier"
2013-03-25Merge branch 'exynos-drm-fixes' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into HEAD Inki writes: Includes bug fixes and code cleanups. And it considers some restrictions to G2D hardware. With this, the malfunction and page fault issues to g2d driver would be fixed. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: Check g2d cmd list for g2d restrictions drm/exynos: Add a new function to get gem buffer size drm/exynos: Deal with g2d buffer info more efficiently drm/exynos: Clean up some G2D codes for readability drm/exynos: Fix G2D core malfunctioning issue drm/exynos: clear node object type at gem unmap drm/exynos: Fix error routine to getting dma addr. drm/exynos: Replaced kzalloc & memcpy with kmemdup drm/exynos: fimd: calculate the correct address offset drm/exynos: Make mixer_check_timing static drm/exynos: modify the compatible string for exynos fimd
2013-03-25ACPI / memhotplug: Remove info->failed bitYasuaki Ishimatsu
acpi_memory_info has enabled bit and failed bit for controlling memory hotplug. But we don't need to keep both bits. The patch removes acpi_memory_info->failed bit. Signed-off-by: yasuaki ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / memhotplug: set info->enabled for memory present at boot timeYasuaki Ishimatsu
At http://marc.info/?l=linux-acpi&m=135769405622667&w=2 thread, Toshi Kani mentioned as follows: "I have a question about the change you made in commit 65479472 in acpi_memhotplug.c. This change seems to require that acpi_memory_enable_device() calls add_memory() to add all memory ranges represented by memory device objects at boot-time, and keep the results be used for hot-remove. If I understand it right, this add_memory() call fails with EEXIST at boot-time since all memory ranges should have been added from EFI memory table (or e820) already. This results all memory ranges be marked as ! enabled & !failed. I think this means that we cannot hot-delete any memory ranges presented at boot-time since acpi_memory_remove_memory() only calls remove_memory() when the enabled flag is set. Is that correct?" Above mention is correct. Thus even if memory device supports hotplug, memory presented at boot-time cannot be hot removed since the memory device's acpi_memory_info->enabled is always 0. This patch changes to set 1 to "acpi_memory_info->enabled" of memory device presented at boot-time for hot removing the memory device. Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / video: Fix applying indexed initial brightness value.Danny Baumann
The value initially read via _BQC also needs to be offset by 2 to compensate for the first 2 special items in _BCL. Introduce a helper function that does the BQC-value-to-level conversion in order to not needlessly duplicate code. Signed-off-by: Danny Baumann <dannybaumann@web.de> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / video: Make logic a little easier to understand.Danny Baumann
Make code paths a little easier to follow, and don't needlessly continue list iteration. Signed-off-by: Danny Baumann <dannybaumann@web.de> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / video: Fix brightness control initialization for some laptops.Danny Baumann
In particular, this fixes brightness control initialization for all devices that return index values from _BQC and don't happen to have the initial index set by the BIOS in their _BCL table. One example for that is the Dell Inspiron 15R SE (model number 7520). What happened for those devices is that acpi_init_brightness queried the initial brightness by calling acpi_video_device_lcd_get_level_current. This called _BQC, which returned e.g. 13. As _BQC_use_index isn't determined at this point (and thus has its initial value of 0), the index isn't converted into the actual level. As '13' isn't present in the _BCL list, *level is later overwritten with brightness->curr, which was initialized to max_level (100) before. Later in acpi_init_brightness, level_old (with the value 100) is used as an index into the _BCL table, which causes a value outside of the actual table to be used as input into acpi_video_device_lcd_set_level(). Depending on the (undefined) value of that location, this call will fail, causing the brightness control for the device in question not to be enabled. Fix that by returning the raw value returned by the _BQC call in the initialization case. Signed-off-by: Danny Baumann <dannybaumann@web.de> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / LPSS: make code less confusing for readerAndy Shevchenko
The excerpt like this: if (err) { err = 0; goto error_out; } makes a reader confused even if it's commented. Let's do necessary actions and return no error explicitly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: Verify device status after ejectToshi Kani
ACPI spec states that the OS evaluates _STA after calling _EJ0 in order to verify if eject was successful. Added a check to verify if the enabled bit of the status value is cleared after _EJ0. Note, the present bit is not checked since some FW implementations do not clear the present bit until the hardware is physically removed. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: Use resource_size() in osl.cAlexandru Gheorghiu
Use the resource_size() function instead of explicit computation. [rjw: Subject and changelog] Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI / acpi_pad: Used PTR_RETAlexandru Gheorghiu
Use PTR_RET instead of explicit checking with IS_ERR. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: suppress compiler warning in container.cAndy Shevchenko
This patch fixes following compiler warning when build via make W=1: drivers/acpi/container.c:183:116: warning: no previous prototype for ‘acpi_container_init’ [-Wmissing-prototypes] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: suppress compiler warning in battery.cAndy Shevchenko
This patch fixes following compiler warning when build via make W=1: drivers/acpi/battery.c:149:52: warning: no previous prototype for ‘acpi_battery_present’ [-Wmissing-prototypes] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: suppress compiler warnings in processor_throttling.cAndy Shevchenko
This patch fixes following compiler warnings when build via make W=1: drivers/acpi/processor_throttling.c: In function ‘acpi_processor_throttling_init’: drivers/acpi/processor_throttling.c:216:40: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-25ACPI: suppress compiler warnings in button.cAndy Shevchenko
This patch fixes following compiler warnings when build via make W=1: drivers/acpi/button.c:220:5: warning: no previous prototype for ‘acpi_lid_notifier_register’ [-Wmissing-prototypes] drivers/acpi/button.c:226:5: warning: no previous prototype for ‘acpi_lid_notifier_unregister’ [-Wmissing-prototypes] drivers/acpi/button.c:232:5: warning: no previous prototype for ‘acpi_lid_open’ [-Wmissing-prototypes] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24acpi: remove reference to ACPI_HOTPLUG_IOPaul Bolle
The Kconfig entry for ACPI Container and Module Devices got added in v2.6.11. Its default value has always been set to (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU || ACPI_HOTPLUG_IO) But the Kconfig symbol ACPI_HOTPLUG_IO has never existed. So it's pointless to use it to set this default value. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: Update _OST handling for notifyToshi Kani
When the kernel calls _OSC with OSC_SB_HOTPLUG_OST_SUPPORT bit set at boot-time, the OS is responsible for calling _OST for ACPI hotplug events. However, when hotplug.enabled attribute is unset for ACPI scan drivers, their notify handlers are removed and _OST is not called for ACPI hotplug events as a result. This patch keeps the notify handler of ACPI scan drivers, acpi_hotplug_notify_cb(), installed regardless of the state of hotplug.enabled. The notify handler then checks if hotplug.enabled is set for the associated scan handler. If unset, the notify handler calls _OST with a proper error code. The patch also eliminates ACPI namespace walk when hotplug.enabled is changed via sysfs. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: Update PNPID match handling for notifyToshi Kani
When installing/removing a notify handler to/from an ACPI device object, ACPI core tries to match its associated scan handler to see if it supports hotplug. However, the matching logic of the notify handler is different from the matching logic of attaching a scan handler to an ACPI device object. This patch updates the matching logic of the notify handlers to be consistent with the attach handling. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: Update PNPID set/free interfacesToshi Kani
This patch introduces acpi_set_pnp_ids() and acpi_free_pnp_ids(), which are updated from acpi_device_set_id() and acpi_free_ids(), to setup and free acpi_device_pnp for a given acpi_handle. They can be called without acpi_device. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: Remove acpi_device dependency in acpi_device_set_id()Toshi Kani
This patch updates the internal operations of acpi_device_set_id() to setup acpi_device_pnp without using acpi_device. There is no functional change to acpi_device_set_id() in this patch. acpi_pnp_type is added to acpi_device_pnp, so that PNPID type is self-contained within acpi_device_pnp. acpi_add_id(), acpi_bay_match(), acpi_dock_match(), acpi_ibm_smbus_match() and acpi_is_video_device() are changed to take acpi_handle as an argument, instead of acpi_device. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: replace kmalloc+memcpy with kmemdupAndrei Epure
Replace the combination of kmalloc() and memcpy() in acpi_run_osc() with a single call to kmemdup(). [rjw: Changelog] Signed-off-by: Andrei Epure <epure.andrei@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI: Remove acpi_pci_bind_root() definitionToshi Kani
Noticed that acpi_pci_bind_root(), which has been deleted, is left defined in acpi_driver.h. So delete this definition from the header as well. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24ACPI video: ignore BIOS backlight value for HP dm4Gustavo Maciel Dias Vieira
On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot, completely dimming the screen. Ignore this initial value for this machine. Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-24tcp: undo spurious timeout after SACK renegingYuchung Cheng
On SACK reneging the sender immediately retransmits and forces a timeout but disables Eifel (undo). If the (buggy) receiver does not drop any packet this can trigger a false slow-start retransmit storm driven by the ACKs of the original packets. This can be detected with undo and TCP timestamps. Signed-off-by: Yuchung Cheng <ycheng@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-24bnx2x: fix assignment of signed expression to unsigned variableKumar Amit Mehta
fix for incorrect assignment of signed expression to unsigned variable. Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com> Acked-by: Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-24bridge: fix crash when set mac address of br interfaceHong zhi guo
When I tried to set mac address of a bridge interface to a mac address which already learned on this bridge, I got system hang. The cause is straight forward: function br_fdb_change_mac_address calls fdb_insert with NULL source nbp. Then an fdb lookup is performed. If an fdb entry is found and it's local, it's OK. But if it's not local, source is dereferenced for printk without NULL check. Signed-off-by: Hong Zhiguo <honkiko@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-248021q: fix a potential use-after-freeCong Wang
vlan_vid_del() could possibly free ->vlan_info after a RCU grace period, however, we may still refer to the freed memory area by 'grp' pointer. Found by code inspection. This patch moves vlan_vid_del() as behind as possible. Cc: Patrick McHardy <kaber@trash.net> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Cong Wang <amwang@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-24net: remove a WARN_ON() in net_enable_timestamp()Eric Dumazet
The WARN_ON(in_interrupt()) in net_enable_timestamp() can get false positive, in socket clone path, run from softirq context : [ 3641.624425] WARNING: at net/core/dev.c:1532 net_enable_timestamp+0x7b/0x80() [ 3641.668811] Call Trace: [ 3641.671254] <IRQ> [<ffffffff80286817>] warn_slowpath_common+0x87/0xc0 [ 3641.677871] [<ffffffff8028686a>] warn_slowpath_null+0x1a/0x20 [ 3641.683683] [<ffffffff80742f8b>] net_enable_timestamp+0x7b/0x80 [ 3641.689668] [<ffffffff80732ce5>] sk_clone_lock+0x425/0x450 [ 3641.695222] [<ffffffff8078db36>] inet_csk_clone_lock+0x16/0x170 [ 3641.701213] [<ffffffff807ae449>] tcp_create_openreq_child+0x29/0x820 [ 3641.707663] [<ffffffff807d62e2>] ? ipt_do_table+0x222/0x670 [ 3641.713354] [<ffffffff807aaf5b>] tcp_v4_syn_recv_sock+0xab/0x3d0 [ 3641.719425] [<ffffffff807af63a>] tcp_check_req+0x3da/0x530 [ 3641.724979] [<ffffffff8078b400>] ? inet_hashinfo_init+0x60/0x80 [ 3641.730964] [<ffffffff807ade6f>] ? tcp_v4_rcv+0x79f/0xbe0 [ 3641.736430] [<ffffffff807ab9bd>] tcp_v4_do_rcv+0x38d/0x4f0 [ 3641.741985] [<ffffffff807ae14a>] tcp_v4_rcv+0xa7a/0xbe0 Its safe at this point because the parent socket owns a reference on the netstamp_needed, so we cant have a 0 -> 1 transition, which requires to lock a mutex. Instead of refining the check, lets remove it, as all known callers are safe. If it ever changes in the future, static_key_slow_inc() will complain anyway. Reported-by: Laurent Chavey <chavey@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-24Merge tag 'pinctrl-fixes-for-v3.9' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pinctrl fixes from Linus Walleij: "Here are a few pinctrl fixes for the v3.9 rc series: - Usecount bounds checking so we do not go below zero on mux usecounts. - Loop range checking in GPIO ranges in the DT range parser. - Proper print in debugfs for pinconf state. - Fix compilation bug in generic pinconf code. - Minor bugfixes to abx500 and mvebu drivers." * tag 'pinctrl-fixes-for-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinmux: forbid mux_usecount to be set at UINT_MAX pinctrl: mvebu: fix checking for SoC specific controls pinctrl: generic: Fix compilation error pinctrl: Print the correct information in debugfs pinconf-state file pinctrl: abx500: Fix checking if pin use AlternateFunction register gpio: fix wrong checking condition for gpio range
2013-03-24Merge branch 'x86/urgent' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "A collection of minor fixes, more EFI variables paranoia (anti-bricking) plus the ability to disable the pstore either as a runtime default or completely, due to bricking concerns." * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE x86, microcode_intel_early: Mark apply_microcode_early() as cpuinit efivars: Handle duplicate names from get_next_variable() efivars: explicitly calculate length of VariableName efivars: Add module parameter to disable use as a pstore backend efivars: Allow disabling use as a pstore backend x86-32, microcode_intel_early: Fix crash with CONFIG_DEBUG_VIRTUAL x86-64: Fix the failure case in copy_user_handle_tail()
2013-03-24Revert "drm/i915: write backlight harder"Daniel Vetter
This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid fixed a regression in 3.6-rc kernels for which we've never figured out the exact root cause. But some further inspection of the backlight code reveals that it's seriously lacking locking. And especially the asle backlight update is know to get fired (through some smm magic) when writing specific backlight control registers. So the possibility of suffering from races is rather real. Until those races are fixed I don't think it makes sense to try further hacks. Which sucks a bit, but sometimes that's how it is :( References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Tested-by: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-24drm/i915: don't disable the power well yetPaulo Zanoni
We're still not 100% ready to disable the power well, so don't disable it for now. When we disable it we break the audio driver (because some of the audio registers are on the power well) and machines with eDP on port D (because it doesn't use TRANSCODER_EDP). Also, instead of just reverting the code, add a Kernel option to let us disable it if we want. This will allow us to keep developing and testing the feature while it's not enabled. This fixes problems caused by the following commit: commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jan 29 16:35:20 2013 -0200 drm/i915: dynamic Haswell display power well support References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Mengdong Lin <mengdong.lin@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-24Revert "drm/i915: set TRANSCODER_EDP even earlier"Daniel Vetter
This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3. The reason is that Takashi Iwai reported a regression bisected to this commit: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html His machine has eDP on port D (usual desktop all-in-on setup), which intel_dp.c identifies as an eDP panel, but the hsw ddi code mishandles. Closer inspection of the code reveals that haswell_crtc_mode_set also checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell that doesn't make much sense (since there's no edp on the pch), but what this function _really_ checks is whether that edp connector is on port A or port D. It's just that on ilk-ivb port D was on the pch ... So that explains why this seemingly innocent change killed eDP on port D. Furthermore it looks like everything else accidentally works, since we've never enabled eDP on port D support for hsw intentionally (e.g. we still register the HDMI output for port D in that case). But in retrospective I also don't like that this leaks highly platform specific details into common code, and the reason is that the drm vblank layer sucks. So instead I think we should: - move the cpu_transcoder into the dynamic pipe_config tracking (once that's merged). - fix up the drm vblank layer to finally deal with kms crtc objects instead of int pipes. v2: Pimp commit message with the better diagnosis as discussed with Paulo on irc. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-24mac80211: Don't restart sta-timer if not associated.Ben Greear
I found another crash when deleting lots of virtual stations in a congested environment. I think the problem is that the ieee80211_mlme_notify_scan_completed could call ieee80211_restart_sta_timer for a stopped interface that was about to be deleted. With the following patch I am unable to reproduce the crash. Signed-off-by: Ben Greear <greearb@candelatech.com> [move check, also make the same change in mesh] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-24cfg80211: always check for scan end on P2P deviceJohannes Berg
If a P2P device wdev is removed while it has a scan, then the scan completion might crash later as it is already freed by that time. To avoid the crash always check the scan completion when the P2P device is being removed for some reason. If the driver already canceled it, don't want and free it, otherwise warn and leak it to avoid later crashes. In order to do this, locking needs to be changed away from the rdev mutex (which can't always be guaranteed). For now, use the sched_scan_mtx instead, I'll rename it to just scan_mtx in a later patch. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-03-23Merge tag 'efi-for-3.9-rc4' into x86/urgentH. Peter Anvin
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-03-24ACPI: Set length even for TYPE_END_TAG acpi resourceYinghai Lu
Found with a network device in QEMU/KVM guest not working anymore. Bisected to commit c13085e5 ACPICA: Resource Mgr: Prevent infinite loops in resource walks That commit will check acpi_resource length strictly which causes acpi_set_current_resources to return failure and IRQ for PCI devices is not set properly. Set length for all those TYPE_END_TAG acpi_resources. [rjw: Changelog] Bisected-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-23Linux 3.9-rc4v3.9-rc4Linus Torvalds
2013-03-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pendingLinus Torvalds
Pull SCSI target fixes from Nicholas Bellinger: "These are mostly minor fixes this time around. The iscsi-target CHAP big-endian bugfix and bump FD_MAX_SECTORS=2048 default patch to allow 1MB sized I/Os for FILEIO backends on >= v3.5 code are both CC'ed to stable. Also, there is a persistent reservations regression that has recently been reported for >= v3.8.x code, that is currently being tracked down for v3.9." * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: target/pscsi: Reject cross page boundary case in pscsi_map_sg target/file: Bump FD_MAX_SECTORS to 2048 to handle 1M sized I/Os tcm_vhost: Flush vhost_work in vhost_scsi_flush() tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint() target: fix possible memory leak in core_tpg_register() target/iscsi: Fix mutual CHAP auth on big-endian arches target_core_sbc: use noop for SYNCHRONIZE_CACHE
2013-03-23Merge tag 'md-3.9-fixes' of git://neil.brown.name/mdLinus Torvalds
Pull md fixes from NeilBrown: "A few bugfixes for md - recent regressions in raid5 - recent regressions in dmraid - a few instances of CONFIG_MULTICORE_RAID456 linger Several tagged for -stable" * tag 'md-3.9-fixes' of git://neil.brown.name/md: md: remove CONFIG_MULTICORE_RAID456 entirely md/raid5: ensure sync and DISCARD don't happen at the same time. MD: Prevent sysfs operations on uninitialized kobjects MD RAID5: Avoid accessing gendisk or queue structs when not available md/raid5: schedule_construction should abort if nothing to do.
2013-03-23Merge tag 'upstream-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev Pull libata updates from Jeff Garzik: "Simple stuff. See one-line summaries." * tag 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: pata_samsung_cf: use module_platform_driver_probe() [libata] Avoid specialized TLA's in ZPODD's Kconfig libata-acpi.c: fix copy and paste mistake in ata_acpi_register_power_resource sata_fsl: Remove redundant NULL check before kfree ahci: Add Device IDs for Intel Wellsburg PCH ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv
2013-03-23Merge branch 'i2c/for-current' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "One bugfix for the tegra driver. Two updates regarding email addresses and MAINTAINERS which I like to have up-to-date so people can be reached immediately. While we are here, there is on PCI_ID addition." * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: add maintainer entry for atmel i2c driver i2c: Fix my e-mail address in drivers and documentation i2c: iSMT: add Intel Avoton DeviceIDs i2c: tegra: check the clk_prepare_enable() return value
2013-03-23Merge git://www.linux-watchdog.org/linux-watchdogLinus Torvalds
Pull watchdog fixes from Wim Van Sebroeck: "Fix a boot issues and correct the AcpiMmioSel bitmask in the sp5100_tco watchdog device driver" * git://www.linux-watchdog.org/linux-watchdog: watchdog: sp5100_tco: Set the AcpiMmioSel bitmask value to 1 instead of 2 watchdog: sp5100_tco: Remove code that may cause a boot failure
2013-03-23KMS: fix EDID detailed timing frame rateTorsten Duwe
When KMS has parsed an EDID "detailed timing", it leaves the frame rate zeroed. Consecutive (debug-) output of that mode thus yields 0 for vsync. This simple fix also speeds up future invocations of drm_mode_vrefresh(). While it is debatable whether this qualifies as a -stable fix I'd apply it for consistency's sake; drm_helper_probe_single_connector_modes() does the same thing already for all probed modes. Cc: stable@vger.kernel.org Signed-off-by: Torsten Duwe <duwe@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-03-23KMS: fix EDID detailed timing vsync parsingTorsten Duwe
EDID spreads some values across multiple bytes; bit-fiddling is needed to retrieve these. The current code to parse "detailed timings" has a cut&paste error that results in a vsync offset of at most 15 lines instead of 63. See http://en.wikipedia.org/wiki/EDID and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why that needs to be a left shift. Cc: stable@vger.kernel.org Signed-off-by: Torsten Duwe <duwe@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-03-22Merge branches 'cxgb4', 'ipoib' and 'qib' into for-nextRoland Dreier