aboutsummaryrefslogtreecommitdiffstats
path: root/fs/9p (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2015-03-04drm/msm: kexec fixesRob Clark2-0/+10
In kexec environment, we are more likely to encounter irq's already enabled from previous environment. At which point we find that writes to disable/clear pending irq's are slightly less than useless without first enabling clocks. TODO: full blown state read-in so kexec'd kernel can inherit the mode already setup. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor blendingRob Clark1-1/+0
Seems like we just want BLEND_EN and not BLEND_TRANSP_EN (setting the latter results in black pixels in the cursor image treated as transparent). Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor ROIRob Clark1-28/+40
If cursor is set near the edge of the screen, it is not valid to use the new cursor width/height as the ROI dimensions. Split out the ROI calc and use it both cursor_set and cursor_move. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/atomic: Don't leak atomic commit object when commit failsLaurent Pinchart1-1/+3
If the atomic commit fails due to completion wait interruption the atomic commit object is not freed and is thus leaked. Free it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: Avoid flushing registers when CRTC is disabledStephane Viau1-7/+19
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL); in that case we should not try to FLUSH registers and do nothing instead. This can happen when we try to move a cursor but the CRTC's CTL (CONTROL) has not been allocated yet (inactive CRTC). It can also happens when we .atomic_check()/.atomic_flush() on a disabled CRTC. A CTL needs to be kept as long as the CRTC is alive. Releasing it after the last VBlank is safer than in .atomic_flush(). Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm: update generated headers (add 6th lm.base entry)Stephane Viau1-11/+4
Some target have up to 6 layer mixers (LM). Let the header file access the last LM's base address. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"Stephane Viau2-5/+5
Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms changes") has a typo in both mdp5_encoder_helper_funcs and mdp5_crtc_helper_funcs definitions: .dpms entry should be replaced by .disable and .enable Also fixed a typo in mdp5_encoder_enable(). Note that these typos are only present for MDP5. MDP4 is fine. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-05drm/ttm: device address space != CPU address spaceAlex Deucher4-4/+4
We need to store device offsets in 64 bit as the device address space may be larger than the CPU's. Fixes GPU init failures on radeons with 4GB or more of vram on 32 bit kernels. We put vram at the start of the GPU's address space so the gart aperture starts at 4 GB causing all GPU addresses in the gart aperture to get truncated. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89072 [airlied: fix warning on nouveau build] Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: thellstrom@vmware.com Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-05drm/mm: Support 4 GiB and larger rangesThierry Reding4-104/+110
The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. [airlied: fix i915 warnings and coloring callback] Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> fixupo
2015-03-04locks: fix fasync_struct memory leak in lease upgrade/downgrade handlingJeff Layton1-1/+2
Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context) introduced a regression in the handling of lease upgrade/downgrades. In the event that we already have a lease on a file and are going to either upgrade or downgrade it, we skip doing any list insertion or deletion and simply re-call lm_setup on the existing lease. As of commit 8634b51f6ca2 however, we end up calling lm_setup on the lease that was passed in, instead of on the existing lease. This causes us to leak the fasync_struct that was allocated in the event that there was not already an existing one (as it always appeared that there wasn't one). Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context) Reported-and-Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
2015-03-04clk: at91: implement suspend/resume for the PMC irqchipBoris BREZILLON2-1/+20
The irq line used by the PMC block is shared with several peripherals including the init timer which is registering its handler with IRQF_NO_SUSPEND. Implement the appropriate suspend/resume callback for the PMC irqchip, and inform irq core that PMC irq handler can be safely called while the system is suspended by setting IRQF_COND_SUSPEND. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04rtc: at91rm9200: rework wakeup and interrupt handlingBoris BREZILLON1-14/+48
The IRQ line used by the RTC device is usually shared with the system timer (PIT) on at91 platforms. Since timers are registering their handlers with IRQF_NO_SUSPEND, we should expect being called in suspended state, and properly wake the system up when this is the case. Set IRQF_COND_SUSPEND flag when registering the IRQ handler to inform irq core that it can safely be called while the system is suspended. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04rtc: at91sam9: rework wakeup and interrupt handlingBoris BREZILLON1-12/+61
The IRQ line used by the RTC device is usually shared with the system timer (PIT) on at91 platforms. Since timers are registering their handlers with IRQF_NO_SUSPEND, we should expect being called in suspended state, and properly wake the system up when this is the case. Set IRQF_COND_SUSPEND flag when registering the IRQ handler to inform irq core that it can safely be called while the system is suspended. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04PM / wakeup: export pm_system_wakeup symbolBoris BREZILLON1-0/+1
Export pm_system_wakeup function to allow irq handlers to deal with system wakeup. This is needed for shared IRQ lines where one of the handler is registered with IRQF_NO_SUSPEND, while the other ones want to configure it as a wakeup source. In this specific case, irq core does not handle the wakeup process and leave the decision to each irq handler. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04genirq / PM: Add flag for shared NO_SUSPEND interrupt linesRafael J. Wysocki4-2/+18
It currently is required that all users of NO_SUSPEND interrupt lines pass the IRQF_NO_SUSPEND flag when requesting the IRQ or the WARN_ON_ONCE() in irq_pm_install_action() will trigger. That is done to warn about situations in which unprepared interrupt handlers may be run unnecessarily for suspended devices and may attempt to access those devices by mistake. However, it may cause drivers that have no technical reasons for using IRQF_NO_SUSPEND to set that flag just because they happen to share the interrupt line with something like a timer. Moreover, the generic handling of wakeup interrupts introduced by commit 9ce7a25849e8 (genirq: Simplify wakeup mechanism) only works for IRQs without any NO_SUSPEND users, so the drivers of wakeup devices needing to use shared NO_SUSPEND interrupt lines for signaling system wakeup generally have to detect wakeup in their interrupt handlers. Thus if they happen to share an interrupt line with a NO_SUSPEND user, they also need to request that their interrupt handlers be run after suspend_device_irqs(). In both cases the reason for using IRQF_NO_SUSPEND is not because the driver in question has a genuine need to run its interrupt handler after suspend_device_irqs(), but because it happens to share the line with some other NO_SUSPEND user. Otherwise, the driver would do without IRQF_NO_SUSPEND just fine. To make it possible to specify that condition explicitly, introduce a new IRQ action handler flag for shared IRQs, IRQF_COND_SUSPEND, that, when set, will indicate to the IRQ core that the interrupt user is generally fine with suspending the IRQ, but it also can tolerate handler invocations after suspend_device_irqs() and, in particular, it is capable of detecting system wakeup and triggering it as appropriate from its interrupt handler. That will allow us to work around a problem with a shared timer interrupt line on at91 platforms. Link: http://marc.info/?l=linux-kernel&m=142252777602084&w=2 Link: http://marc.info/?t=142252775300011&r=1&w=2 Link: https://lkml.org/lkml/2014/12/15/552 Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2015-03-04ASoC: omap-pcm: Correct dma maskPeter Ujfalusi1-1/+1
DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be set to 32. The 64 was introduced by commit (in 2009): a152ff24b978 ASoC: OMAP: Make DMA 64 aligned But the dma_mask and coherent_dma_mask can not be used to specify alignment. Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned) Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-04ACPI / video: Propagate the error code for acpi_video_registerChris Wilson1-4/+5
Report the actual error code from acpi_bus_register_driver(), it may help future debugging (typically ENODEV as previously reported, but the unusual cases are where it may help most). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04ACPI / video: Load the module even if ACPI is disabledChris Wilson1-0/+11
i915.ko depends upon the acpi/video.ko module and so refuses to load if ACPI is disabled at runtime if for example the BIOS is broken beyond repair. acpi/video provides an optional service for i915.ko and so we should just allow the modules to load, but do no nothing in order to let the machines boot correctly. Reported-by: Bill Augur <bill-auger@programmer.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: All applicable <stable@vger.kernel.org> Acked-by: Aaron Lu <aaron.lu@intel.com> [ rjw: Fixed up the new comment in acpi_video_init() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04PM / Domains: cleanup: rename gpd -> genpd in debugfs interfaceKevin Hilman1-12/+12
To keep consisitency with the rest of the file, use 'genpd' as the name of the 'struct generic_pm_domain' pointer instead of 'gpd'. This is just a rename, no functional changes. Signed-off-by: Kevin Hilman <khilman@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04cpufreq: ppc: Add missing #include <asm/smp.h>Geert Uytterhoeven1-0/+2
If CONFIG_SMP=n, <linux/smp.h> does not include <asm/smp.h>, causing: drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init': drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration] Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugsJiang Liu1-1/+3
Some BIOSes report incorrect length for ACPI address space descriptors, so relax the checks to avoid regressions. This issue has appeared several times as: 3162b6f0c5e1 ("PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1") d558b483d5a7 ("x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1") f238b414a74a ("PNPACPI: compute Address Space length rather than using _LEN") 48728e077480 ("x86/PCI: compute Address Space length rather than using _LEN") Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221 for more details and example malformed ACPI resource descriptors. Link: https://bugzilla.kernel.org/show_bug.cgi?id=94221 Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...) Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Tested-by: Dave Airlie <airlied@redhat.com> Tested-by: Prakash Punnoor <prakash@punnoor.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04x86/PCI/ACPI: Ignore resources consumed by host bridge itselfJiang Liu1-3/+8
When parsing resources for PCI host bridge, we should ignore resources consumed by host bridge itself and only report window resources available to child PCI busses. Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...) Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04dma: mmp-tdma: refine dma disable and dma-pos updateQiao Zhou1-6/+25
Below are the refinements. 1. Set DMA abort bit when disabling dma channel. This will clear the remaining data in dma FIFO, to fix channel-swap issue. 2. Read DMA HW pointer when updating DMA status. Previously dma position is calculated by adding one period size in dma interrupt. This is inaccurate/insufficient for some high-quality audio APP. Since interrupt bottom half handler has variable schedule delay, it causes big error when calculating sample delay. Read the actual HW pointer and feedback can improve the accuracy. 3. Do some minor code clean. Signed-off-by: Qiao Zhou <zhouqiao@marvell.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-03-04drm/i915: gen4: work around hang during hibernationImre Deak1-5/+25
Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. v2: - Another GEN4 Lenovo laptop had the same issue, while platforms from other vendors (including mobile and desktop, GEN4 and non-GEN4) seem to work fine. Based on this apply the workaround on all GEN4 Lenovo platforms. - add code comment about failing platforms (Ville) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork <bjorn@mork.no> Cc: stable@vger.kernel.org # v3.19 Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-04drm/i915: Check for driver readyness before handling an underrun interruptChris Wilson1-11/+7
When we takeover from the BIOS and install our interrupt handler, the BIOS may have left us a few surprises in the form of spontaneous interrupts. (This is especially likely on hardware like 965gm where display fifo underruns are continuous and the GMCH cannot filter that interrupt souce.) As we enable our IRQ early so that we can use it during hardware probing, our interrupt handler must be prepared to handle a few sources prior to being fully configured. As such, we need to add a simple is-ready check prior to dereferencing our KMS state for reporting underruns. Reported-by: Rob Clark <rclark@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org [Jani: dropped the extra !] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-03NFSv4.1: Clear the old state by our client id before establishing a new leaseTrond Myklebust3-5/+17
If the call to exchange-id returns with the EXCHGID4_FLAG_CONFIRMED_R flag set, then that means our lease was established by a previous mount instance. Ensure that we detect this situation, and that we clear the state held by that mount. Reported-by: Jorge Mora <Jorge.Mora@netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-03-04powerpc/iommu: Remove IOMMU device references via bus notifierNishanth Aravamudan4-26/+34
After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the refcnt on the kobject backing the IOMMU group for a PCI device is elevated by each call to pci_dma_dev_setup_pSeriesLP() (via set_iommu_table_base_and_group). When we go to dlpar a multi-function PCI device out: iommu_reconfig_notifier -> iommu_free_table -> iommu_group_put BUG_ON(tbl->it_group) We trip this BUG_ON, because there are still references on the table, so it is not freed. Fix this by moving the powernv bus notifier to common code and calling it for both powernv and pseries. Fixes: d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier") Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Tested-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-04powerpc/smp: Wait until secondaries are active & onlineMichael Ellerman1-2/+2
Anton has a busy ppc64le KVM box where guests sometimes hit the infamous "kernel BUG at kernel/smpboot.c:134!" issue during boot: BUG_ON(td->cpu != smp_processor_id()); Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops output confirms it: CPU: 0 Comm: watchdog/130 The problem is that we aren't ensuring the CPU active bit is set for the secondary before allowing the master to continue on. The master unparks the secondary CPU's kthreads and the scheduler looks for a CPU to run on. It calls select_task_rq() and realises the suggested CPU is not in the cpus_allowed mask. It then ends up in select_fallback_rq(), and since the active bit isnt't set we choose some other CPU to run on. This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug vs. set_cpus_allowed_ptr()", which changed from setting active before online to setting active after online. However that was in turn fixing a bug where other code assumed an active CPU was also online, so we can't just revert that fix. The simplest fix is just to spin waiting for both active & online to be set. We already have a barrier prior to set_cpu_online() (which also sets active), to ensure all other setup is completed before online & active are set. Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-03NFSv4: Fix a race in NFSv4.1 server trunking discoveryTrond Myklebust3-8/+17
We do not want to allow a race with another NFS mount to cause nfs41_walk_client_list() to establish a lease on our nfs_client before we're done checking for trunking. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2015-03-03drm/radeon: fix interlaced modes on DCE8Alex Deucher1-0/+3
Need to double the viewport height. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: fix DRM_IOCTL_RADEON_CS oopsTommi Rantala1-1/+3
Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include <stdint.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/radeon_drm.h> static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640 [ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570 [ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0 [ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP <ffff880058e67998> [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in cik_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in si_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in evergreen_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r600_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in rs600_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r100_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03radeon/audio: fix DP audio on DCE6Slava Grigorev2-4/+12
Split DCE6 and DCE8 programming of DCCG_AUDIO_DTO1 registers to properly enable DP audio for both DCE revisions. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03radeon/audio: fix whitespaceSlava Grigorev1-16/+16
Use proper tabs. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: adjust audio callback orderAlex Deucher1-14/+16
- Move it out of the UNIPHY case to handle older DCE blocks. - set audio dpms before video dpms Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: properly set dto for dp on DCE4/5Alex Deucher2-3/+10
If DCPLL or ext PLL is used, use the disp clk. If PPLL is used, use the dp clock. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: update EDID derived fields in modesetAlex Deucher1-5/+6
We don't necessarily have an EDID at this point when audio detect gets called. Ideally we'd update these fields in detect, but that requires a larger rework of the display detect code. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: don't toggle audio state in modesetAlex Deucher1-12/+1
Should be done only at detect time to avoid spurious state changes on the audio side. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: set mute around state setupAlex Deucher1-1/+2
To avoid possible sound artifacts while setting up audio. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: assign pin in detectAlex Deucher1-3/+3
We need the pin from detect on, it's too late in dpms. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: fix the audio dpms callbacksAlex Deucher4-70/+32
Don't touch the audio enable bits as these are already handled in display detection. Enable the hdmi secondary streams in hdmi enable to match dp. Rename dp dpms callback to be consistent with hdmi. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89327 https://bugzilla.kernel.org/show_bug.cgi?id=93921 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03openvswitch: Fix serialization of non-masked set actions.Joe Stringer1-1/+7
Set actions consist of a regular OVS_KEY_ATTR_* attribute nested inside of a OVS_ACTION_ATTR_SET action attribute. When converting masked actions back to regular set actions, the inner attribute length was not changed, ie, double the length being serialized. This patch fixes the bug. Fixes: 83d2b9b ("net: openvswitch: Support masked set actions.") Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-03gianfar: Reduce logging noise seen due to phy polling if link is downGuenter Roeck1-2/+2
Commit 6ce29b0e2a04 ("gianfar: Avoid unnecessary reg accesses in adjust_link()") eliminates unnecessary calls to adjust_link for phy devices which don't support interrupts and need polling. As part of that work, the 'new_state' local flag, which was used to reduce logging noise on the console, was eliminated. Unfortunately, that means that a 'Link is Down' log message will now be issued continuously if a link is configured as UP, the link state is down, and the associated phy requires polling. This occurs because priv->oldduplex is -1 in this case, which always differs from phydev->duplex. In addition, phydev->speed may also differ from priv->oldspeed. gfar_update_link_state() is therefore called each time a phy is polled, even if the link state did not change. Cc: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-03ibmveth: Add function to enable live MAC address changesThomas Falcon1-1/+23
Add a function that will enable changing the MAC address of an ibmveth interface while it is still running. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Reviewed-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-03net: bridge: add compile-time assert for cb struct sizeFlorian Westphal1-0/+2
make build fail if structure no longer fits into ->cb storage. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>