summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-12-18bonding: protect port for bond_3ad_adapter_duplex_changed()dingtianhong
Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is called with RTNL only, and the function will modify the port's information with no further locking, it will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add __get_state_machine_lock to protect the port. But it is not a critical bug, it exist since day one, and till now it has never been hit and reported, because changes to speed is very rare, and will not occur critical problem. The comments in the function is very old, cleanup it. Suggested-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-18bonding: protect port for bond_3ad_adapter_speed_changed()dingtianhong
Jay Vosburgh said that the bond_3ad_adapter_speed_changed is called with RTNL only, and the function will modify the port's information with no further locking, it will not mutex against bond state machine and incoming LACPDU which do not hold RTNL, So I add __get_state_machine_lock to protect the port. But it is not a critical bug, it exist since day one, and till now it has never been hit and reported, because changes to speed is very rare, and will not occur critical problem. The comment in the function is very old, cleanup it. Suggested-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-18net_dma: mark brokenDan Williams
net_dma can cause data to be copied to a stale mapping if a copy-on-write fault occurs during dma. The application sees missing data. The following trace is triggered by modifying the kernel to WARN if it ever triggers copy-on-write on a page that is undergoing dma: WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120() ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9] Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca CPU: 24 PID: 2529 Comm: linbug Tainted: G W 3.13.0-rc1+ #353 00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70 ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646 ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349 Call Trace: [<ffffffff81751041>] dump_stack+0x46/0x58 [<ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0 [<ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30 [<ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50 [<ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120 [<ffffffff81154a40>] do_wp_page+0xd0/0x790 [<ffffffff811582ac>] handle_mm_fault+0x51c/0xde0 [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20 [<ffffffff8175fc2c>] __do_page_fault+0x19c/0x530 [<ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40 [<ffffffff810f3539>] ? trace_clock_local+0x9/0x10 [<ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310 [<ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma] [<ffffffff8175ffce>] do_page_fault+0xe/0x10 [<ffffffff8175c862>] page_fault+0x22/0x30 [<ffffffff81643991>] ? __kfree_skb+0x51/0xd0 [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20 [<ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0 [<ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0 [<ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0 [<ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0 [..] ---[ end trace e30e3b01191b7617 ]--- Mapped at: [<ffffffff8139c169>] debug_dma_map_page+0xb9/0x160 [<ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210 [<ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0 [<ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0 [<ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0: ...the problem is that the receive path falls back to cpu-copy in several locations and this trace is just one of the areas. A few options were considered to fix this: 1/ sync all dma whenever a cpu copy branch is taken 2/ modify the page fault handler to hold off while dma is in-flight Option 1 adds yet more cpu overhead to an "offload" that struggles to compete with cpu-copy. Option 2 adds checks for behavior that is already documented as broken when using get_user_pages(). At a minimum a debug mode is warranted to catch and flag these violations of the dma-api vs get_user_pages(). Thanks to David for his reproducer. Cc: <stable@vger.kernel.org> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Alexander Duyck <alexander.h.duyck@intel.com> Reported-by: David Whipple <whipple@securedatainnovations.ch> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2013-12-18powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)Gerhard Sittig
the 'soc' node in the MPC5125 "tower" board .dts has an '#interrupt-cells' property although this node is not an interrupt controller remove this erroneously placed property because starting with v3.13-rc1 lookup and resolution of 'interrupts' specs for peripherals gets misled (tries to use the 'soc' as the interrupt parent which fails), emits 'no irq domain found' WARN() messages and breaks the boot process [ best viewed with 'git diff -U5' to have DT node names in the context ] Cc: Anatolij Gustschin <agust@denx.de> Cc: linuxppc-dev@lists.ozlabs.org Cc: devicetree@vger.kernel.org Signed-off-by: Gerhard Sittig <gsi@denx.de> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2013-12-18Merge branch 'for-upstream' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
2013-12-18dma: pl330: ensure DMA descriptors are zero-initialisedWill Deacon
I see the following splat with 3.13-rc1 when attempting to perform DMA: [ 253.004516] Alignment trap: not handling instruction e1902f9f at [<c0204b40>] [ 253.004583] Unhandled fault: alignment exception (0x221) at 0xdfdfdfd7 [ 253.004646] Internal error: : 221 [#1] PREEMPT SMP ARM [ 253.004691] Modules linked in: dmatest(+) [last unloaded: dmatest] [ 253.004798] CPU: 0 PID: 671 Comm: kthreadd Not tainted 3.13.0-rc1+ #2 [ 253.004864] task: df9b0900 ti: df03e000 task.ti: df03e000 [ 253.004937] PC is at dmaengine_unmap_put+0x14/0x34 [ 253.005010] LR is at pl330_tasklet+0x3c8/0x550 [ 253.005087] pc : [<c0204b44>] lr : [<c0207478>] psr: a00e0193 [ 253.005087] sp : df03fe48 ip : 00000000 fp : df03bf18 [ 253.005178] r10: bf00e108 r9 : 00000001 r8 : 00000000 [ 253.005245] r7 : df837040 r6 : dfb41800 r5 : df837048 r4 : df837000 [ 253.005316] r3 : dfdfdfcf r2 : dfb41f80 r1 : df837048 r0 : dfdfdfd7 [ 253.005384] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 253.005459] Control: 30c5387d Table: 9fb9ba80 DAC: fffffffd [ 253.005520] Process kthreadd (pid: 671, stack limit = 0xdf03e248) This is due to desc->txd.unmap containing garbage (uninitialised memory). Rather than add another dummy initialisation to _init_desc, instead ensure that the descriptors are zero-initialised during allocation and remove the dummy, per-field initialisation. Cc: Andriy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2013-12-18s390/3270: fix allocation of tty3270_screen structureMartin Schwidefsky
The tty3270_alloc_screen function is called from tty3270_install with swapped arguments, the number of columns instead of rows and vice versa. The number of rows is typically smaller than the number of columns which makes the screen array too big but the individual cell arrays for the lines too small. Creating lines longer than the number of rows will clobber the memory after the end of the cell array. The fix is simple, call tty3270_alloc_screen with the correct argument order. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-12-18s390/smp: improve setup of possible cpu maskHeiko Carstens
Since under z/VM we cannot have more than 64 cpus, make sure the cpu_possible_mask does not contain more bits. This avoids wasting memory for dynamic per-cpu allocations if CONFIG_NR_CPUS is larger than 64. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-12-18drm/i915: grab a pages pin count for preallocate stolenDaniel Vetter
But only when we indeed set up a gtt mapping. We need this since the vma also holds a pages_pin_count, on top of the unconditional pages_pin_count we grab for all stolen objects (to avoid swap-out). This should avoid a pages_pin_count underrun when cleaning up framebuffers objects taken over from the BIOS. Chris mentioned in his review that this bug even predates the vma conversion. Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-18ALSA: hda - Add Dell headset detection quirk for one more laptop modelHui Wang
On the Dell machines with codec whose Subsystem Id is 0x10280640, no external microphone can be detected when plugging a 3-ring headset. Using ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix this problem. The codec (Vendor ID: 0x10ec0255) on the machine belongs to alc_269 family. BugLink: https://bugs.launchpad.net/bugs/1260303 Cc: David Henningsson <david.henningsson@canonical.com> Cc: stable@vger.kernel.org Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-12-18ASoC: wm8904: fix DSP mode B configurationBo Shen
When wm8904 work in DSP mode B, we still need to configure it to work in DSP mode. Or else, it will work in Right Justified mode. Signed-off-by: Bo Shen <voice.shen@atmel.com> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
2013-12-18ASoC: wm_adsp: Add small delay while polling DSP RAM startCharles Keepax
Some devices are getting very close to the limit whilst polling the RAM start, this patch adds a small delay to this loop to give a longer startup timeout. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
2013-12-18KVM: PPC: Book3S HV: Don't drop low-order page address bitsPaul Mackerras
Commit caaa4c804fae ("KVM: PPC: Book3S HV: Fix physical address calculations") unfortunately resulted in some low-order address bits getting dropped in the case where the guest is creating a 4k HPTE and the host page size is 64k. By getting the low-order bits from hva rather than gpa we miss out on bits 12 - 15 in this case, since hva is at page granularity. This puts the missing bits back in. Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-18powerpc: book3s: kvm: Don't abuse host r2 in exit pathAneesh Kumar K.V
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR KVM mode when both HV and PR are enabled in the kernel. Without this we get the below crash (qemu) Unable to handle kernel paging request for data at address 0xffffffffffff8310 Faulting instruction address: 0xc00000000001d5a4 cpu 0x2: Vector: 300 (Data Access) at [c0000001dc53aef0] pc: c00000000001d5a4: .vtime_delta.isra.1+0x34/0x1d0 lr: c00000000001d760: .vtime_account_system+0x20/0x60 sp: c0000001dc53b170 msr: 8000000000009032 dar: ffffffffffff8310 dsisr: 40000000 current = 0xc0000001d76c62d0 paca = 0xc00000000fef1100 softe: 0 irq_happened: 0x01 pid = 4472, comm = qemu-system-ppc enter ? for help [c0000001dc53b200] c00000000001d760 .vtime_account_system+0x20/0x60 [c0000001dc53b290] c00000000008d050 .kvmppc_handle_exit_pr+0x60/0xa50 [c0000001dc53b340] c00000000008f51c kvm_start_lightweight+0xb4/0xc4 [c0000001dc53b510] c00000000008cdf0 .kvmppc_vcpu_run_pr+0x150/0x2e0 [c0000001dc53b9e0] c00000000008341c .kvmppc_vcpu_run+0x2c/0x40 [c0000001dc53ba50] c000000000080af4 .kvm_arch_vcpu_ioctl_run+0x54/0x1b0 [c0000001dc53bae0] c00000000007b4c8 .kvm_vcpu_ioctl+0x478/0x730 [c0000001dc53bca0] c0000000002140cc .do_vfs_ioctl+0x4ac/0x770 [c0000001dc53bd80] c0000000002143e8 .SyS_ioctl+0x58/0xb0 [c0000001dc53be30] c000000000009e58 syscall_exit+0x0/0x98 Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-17ixgbe: fix for unused variable warning with certain configDon Skidmore
If CONFIG_PCI_IOV isn't defined we get an "unused variable" warining so now wrap the variable declaration like it's usage already was. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-12-17e1000e: Fix a compile flag mis-match for suspend/resumeDavid Ertman
This patch addresses a mis-match between the declaration and usage of the e1000_suspend and e1000_resume functions. Previously, these functions were declared in a CONFIG_PM_SLEEP wrapper, and then utilized within a CONFIG_PM wrapper. Both the declaration and usage will now be contained within CONFIG_PM wrappers. Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-12-17e1000e: fix compiler warning (maybe-unitialized variable)David Ertman
This patch is to fix a compiler warning of maybe-uininitialized-variable that is generated from gcc when the -O3 flag is used. In the function e1000_reset_hw_80003es2lan(), the variable krmn_reg_data is first given a value by being passed to a register read function as a pass-by-reference parameter. But, the return value of that read function was never checked to see if the read failed and the variable not given an initial value. The compiler was smart enough to spot this. This patch is to check the return value for that read function and return it, if an error occurs, without trying to utilize the value in kmrn_reg_data. Signed-off-by: David Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-12-17e1000e: fix compiler warningsDavid Ertman
This patch is to fix a compiler warning of __bad_udelay due to a value of >999 being passed as a parameter to udelay() in the function e1000e_phy_has_link_generic(). This affects the gcc compiler when it is given a flag of -O3 and the icc compiler. This patch is also making the change from mdelay() to msleep() in the same function, since it was determined though code inspection that this function is never called in atomic context. Signed-off-by: David Ertman <davidx.m.ertman@intel.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-12-18ext4: fix deadlock when writing in ENOSPC conditionsJan Kara
Akira-san has been reporting rare deadlocks of his machine when running xfstests test 269 on ext4 filesystem. The problem turned out to be in ext4_da_reserve_metadata() and ext4_da_reserve_space() which called ext4_should_retry_alloc() while holding i_data_sem. Since ext4_should_retry_alloc() can force a transaction commit, this is a lock ordering violation and leads to deadlocks. Fix the problem by just removing the retry loops. These functions should just report ENOSPC to the caller (e.g. ext4_da_write_begin()) and that function must take care of retrying after dropping all necessary locks. Reported-and-tested-by: Akira Fujita <a-fujita@rs.jp.nec.com> Reviewed-by: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org
2013-12-17net: allow netdev_all_upper_get_next_dev_rcu with rtnl lock heldJohn Fastabend
It is useful to be able to walk all upper devices when bringing a device online where the RTNL lock is held. In this case it is safe to walk the all_adj_list because the RTNL lock is used to protect the write side as well. This patch adds a check to see if the rtnl lock is held before throwing a warning in netdev_all_upper_get_next_dev_rcu(). Also because we now have a call site for lockdep_rtnl_is_held() outside COFIG_LOCK_PROVING an inline definition returning 1 is needed. Similar to the rcu_read_lock_is_held(). Fixes: 2a47fa45d4df ("ixgbe: enable l2 forwarding acceleration for macvlans") CC: Veaceslav Falico <vfalico@redhat.com> Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2013-12-18drm/dp: Clarify automated test constant and add constant for FAUX test patternTodd Previte
- DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN to clarify - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: use memdup_user() as a cleanupDan Carpenter
drivers/gpu/drm/r128/r128_state.c:1014:10-17: WARNING opportunity for memdup_user /c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:1029:9-16: WARNING opportunity for memdup_user /c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:904:10-17: WARNING opportunity for memdup_user /c/kernel-tests/src/cocci/drivers/gpu/drm/r128/r128_state.c:914:9-16: WARNING opportunity for memdup_user Use memdup_user rather than duplicating its implementation This is a little bit restricted to reduce false positives Generated by: coccinelle/api/memdup_user.cocci CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: remove dev->vma_countDaniel Vetter
This is just used for a debugfs file, and we can easily reconstruct this number by just walking the list twice. Which isn't really bad for a debugfs file anyway. So let's rip this out. There's the other issue that the dev->vmalist itself is a bit useless, since that can be reconstructed with all the memory mapping information from proc. But remove that is a different topic entirely. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill file_priv->ioctl_count trackingDaniel Vetter
It's racy, and it's only used in debugfs. There are simpler ways to know whether something is going on (like looking at dmesg with full debugging enabled). And they're all much more useful. So let's just rip this out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: rip out dev->ioctl_count trackingDaniel Vetter
Now dev->ioctl_count tries to prevent the device from disappearing if it's still in use. And if we'd actually need this code it would be hopelessly racy and broken. But luckily the vfs already takes care of this. So we can just rip it out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm/gma500: Remove dead codeDaniel Vetter
This has the nice advantage that we'll get rid of a DRM_WAIT_ON user for free. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_SUSERDaniel Vetter
Checking directly for the right capability is simpler. Also this rids us of a few places that use DRM_CURRENTPID. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_*MEMORYBARRIERDaniel Vetter
The real linux interfaces are soooo much easier on the eyes ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_COPY_(TO|FROM)_USERDaniel Vetter
Less yelling ftw! Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_WAKUP and DRM_INIT_WAITQUEUEDaniel Vetter
Less yelling ftw! Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_IRQ_ARGSDaniel Vetter
I've killed them a long time ago in drm/i915, let's get rid of this remnant of shared drm core days for good. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: Kill DRM_HZDaniel Vetter
We don't have any userspace interfaces that use HZ as a time unit, so having our own DRM define is useless. Remove this remnant from the shared drm core days. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: rip out DRM_AGP_MEM and DRM_AGP_KERNDaniel Vetter
The <linux/agp_backend.h> header provides dummy functions and fallbacks, so no need for screaming macros. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: remove global_mutex locking around agp_initDaniel Vetter
David Herrmann dutifully moved this locking along when moving the agp_init call out of the generic drm_dev_register into the pci specific load helpers. But afaict there's no need and the reason for that locking has been purely a historical accident - we need the lock around the driver dev node registration to paper over the midlayer init races, and the agp init simply ended up in there. The real fix for all this is of course to delay the dev (and sysfs/debugfs) interface registration until everything is fully set up. Until then stop the cargo-cult locking from spreading and remove the locking. Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm/agpsupport: use kzalloc instead of kmalloc/memsetDave Airlie
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: kill the ->agp_destroy callbackDaniel Vetter
Call drm_pci_agp_destroy directly, there's no point in the indirection. Long term we want to shuffle this into each driver's unload logic, but that needs cleared-up drm lifetime rules first. v2: Add a dummy function for !CONFIG_PCI, spotted my David Herrmann. v3: Fixup for the coding style police. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: inline drm_agp_destroyDaniel Vetter
Wrapping a kfree is pointless. v2: Add a comment to the kerneldoc for drm_agp_init to explain where the kfree happens as requested by David. Note that for modeset drivers agp cleanup is fairly complicated anyway: The drm_agp_clear is a noop and drivers must call drm_agp_release on their own. Which they all seem to do properly. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: remove agp_init() bus callbackDaniel Vetter
The PCI bus helper is the only user of it. Call it directly before device-registration to get rid of the callback. Note that all drm_agp_*() calls are locked with the drm-global-mutex so we need to explicitly lock it during initialization. It's not really clear why it's needed, but lets be safe. v2: Rebase on top of the agp_init interface change. v3: Remove the rebase-fail where I've accidentally killed the ->irq_by_busid callback a bit too early. Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: rip out drm_core_has_AGPDaniel Vetter
Most place actually want to just check for dev->agp (most do, but a few don't so this fixes a few potential NULL derefs). The only exception is the agp init code which should check for the AGP driver feature flag. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: ->agp_init can't failDaniel Vetter
Thanks to the removal of REQUIRE_AGP we can use a void return value and shed a bit of complexity. Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: kill DRIVER_REQUIRE_AGPDaniel Vetter
Only the two intel drivers need this and they can easily check for working agp support in their driver ->load callbacks. This is the only reason why agp initialization could fail, so allows us to rip out a bit of error handling code in the next patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-17imx-drm: imx-drm-core: improve safety of imx_drm_add_crtc()Russell King
We must not add more CRTCs than we have declared to the vblank helpers, otherwise we overflow their arrays. Force failure if we exceed the number of CRTCs. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-17imx-drm: imx-drm-core: make imx_drm_crtc_register() saferRussell King
imx_drm_crtc_register() doesn't clean up the CRTC upon failure, which leaves the CRTC attached to the DRM device. Also, it does setup after attaching the CRTC to the DRM device. Fix this by reordering the function such that we do the setup before drm_crtc_init(): this fixes both issues. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-17imx-drm: imx-drm-core: use defined constant for number of CRTCs.Russell King
We have this definition, there's no reason not to use it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-17imx-drm: imx-tve: don't call sleeping functions beneath enable_lock spinlockRussell King
Enable lock claims that it is serializing tve_enable/disable calls. However, DRM already serialises mode sets with a mutex, which prevents encoder/connector functions being called concurrently. Secondly, holding a spinlock while calling clk_prepare_enable() is wrong; it will cause a might_sleep() warning should that debugging be enabled. So, let's just get rid of the enable_lock. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-17imx-drm: ipu-v3: fix potential CRTC device registration raceRussell King
Clean up the IPUv3 CRTC device registration; we don't need a separate function just to call platform_device_register_data(), and we don't need the return value converted at all. Update the IPU client id under a mutex, so that parallel probing doesn't race. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-18drm/rcar-du: Fix return value check in rcar_du_lvdsenc_get_resources()Wei Yongjun
In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Also remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> [Remove the unneeded mem == NULL check] Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-17imx-drm: imx-drm-core: fix DRM cleanup pathsRussell King
We must call drm_vblank_cleanup() on the error cleanup and unload paths after we've had a successful call to drm_vblank_init(). Ensure that the calls are in the reverse order to the initialisation order. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-17imx-drm: imx-drm-core: fix error cleanup path for imx_drm_add_crtc()Russell King
imx_drm_add_crtc() was kfree'ing the imx_drm_crtc structure while leaving it on the list of CRTCs. Delete it from the list first. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-18drm/dp: Use AUX constants from specificationThierry Reding
The current values seem to be defined in a format that's specific to the i915, gma500 and radeon drivers. To make this more generally useful, use the values as defined in the specification. While at it, prefix the constants with DP_ for improved namespacing. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-13 19:29:20 +0000