Especially not on modesetting drivers - this is used to size
the driver private structure for legacy drm buffers.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.
The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.
With that converted we can rip out all the ->get_name implementations.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.
Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So just rip it out to
simplify the set_version/set_busid insanity a bit.
Also delete the temporary busname from drm_pci_set_busid, it's now
unused.
v2: Rebase on top of the new host1x drm_bus for tegra.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.
v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.
v3: Fix spelling in comment (Thierry)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only ever called for legacy drivers, which are all pci.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
v2: Add the hunk lost in an earlier patch to this one (Thierry).
v3: Fix up the totally fumbled logic in drm_irq_install and use the
local variable consistently. Spotted by both Thierry and Laurent.
Shame on me for failing to properly test the rebase version of this
patch ...
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.
v2: Move the spurious hunk to the right patch (Thierry).
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
paths.
- It wouldn't actually protect anything, for that we'd need to wrap
the entire vga switcheroo code in the drm_global_mutex. And I'm not
sure whether that would actually solve anything.
What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.
But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.
v2:
- Simplify the ->can_switch implementations more (Thierry)
- Fix comment about the dev->open_count locking (Thierry)
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.
The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.
This regression was introduced in
commit e9cb81a228
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Nov 21 13:47:23 2013 -0200
drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Newer elantech touchpads are not recognized by the current driver, since it
fails to detect their firmware version number. This prevents more advanced
touchpad features from being usable such as two-finger scrolling. This
patch allows newer touchpads to be detected and be fully functional. Tested
on Sony Vaio SVF13N17PXB.
Signed-off-by: Jordan Rife <jrife0@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When the system has zero or one button available, trying to rmmod
soc_button_array will cause crash. Fix this by properly handling -ENODEV
in probe().
Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTSX1HAAoJEFSFNJnE9BaIGkoQAIotGana51TXPo9KYnQJaCYH
+xBfaaXEaR69lARoXT8SDGzyXPCQNOEbVfsXRwrVQ4Wl8x2hP8n9YdUrAHzZ/8O/
Wf8Z0jb81Q+KNJ+SMMgcy4kK5OU71EMMk5fbocPzD+WfQ+WlDr+My1F3yZ5UIvOM
nOUF6QCcYA0MN7dopEVIqyP8HZhrxR1YUvgzqOmp1fteYL4gFCU006WPSI30GxEv
fMM8MiWbbn9xjOsR7SBzaLEo0Hv3YC92zwSAuJxGClH/+9cKogWAaE/PiNUO3y6A
+2D0KQnGRopKy4j/QCjdPZsTmYDBxQ9vMlUOtRlOf1XAVjL6pZu2EJ2/ereShLW6
B4rev23tqgk9nyNk/Li4n+5krzvPqqOcbWNW1la769DkEt7LU+YU+hiShkDm1+0M
6hwxPd6gQxg0QUjuusi1+B5JqweAv+mEcCsQ+ga6ZK61X9bNJ6c/4YF451rkNhc6
mlC3ZqBvDALmNSVdCas0GOGHLaeWxfoT7E9G6p62h9uBVerqZ6epvlAUC6JOHotc
/qz/D1VL1+ptPAawXiFSNOb8RMJogdBfjPB9bOlYQSSHV3eF0RVNK6FQiqvc4mFX
or1pPG6lDLGm6g3NcDEjxEEVThevQpEwKmpM0TCEUMiIuxSHYN/M//P2PSeDvYwk
9k8x3fJae7dWNsGIT92y
=HMr3
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.15a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First found of IIO fixes for the 3.15 cycle.
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
1. Further PLL parameter fixes.
2. Fixes for HPD on DP
3. Could of different PM fixes
4. Disabling DPM on RV770
* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: don't allow runpm=1 on systems with out ATPX
drm/radeon: fix ATPX detection on non-VGA GPUs
drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)
drm/radeon: properly unregister hwmon interface (v2)
drm/radeon: fix count in cik_sdma_ring_test()
drm/radeon/aux: fix hpd assignment for aux bus
drm/radeon: improve PLL limit handling in post div calculation
drm/radeon: use fixed PPL ref divider if needed
drm/radeon: disable dpm on rv770 by default
Fix e26a9e00af 'ARM: Better
virt_to_page() handling' replaced __pv_phys_offset with
__pv_phys_pfn_offset. Also note that size of __pv_phys_offset
was quad but size of __pv_phys_pfn_offset is word. Instruction
that used to update __pv_phys_offset which address is in r6
had to update low word of __pv_phys_offset so it used #LOW_OFFSET
macro for store offset. Now when size of __pv_phys_pfn_offset is
word, no difference between little endian and big endian should
exist - i.e no offset should be used when __pv_phys_pfn_offset
is stored.
Note that for little endian image proposed change is noop,
since in little endian case #LOW_OFFSET is defined 0 anyway.
Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The switcher should not depend on MAX_CLUSTER to determine ifit should
be activated or not. In a multiplatform kernel binary it is possible to
have dual-cluster and quad-cluster platforms configured in. In that case
MAX_CLUSTER which is a build time limit should be 4 and that shouldn't
prevent the switcher from working if the kernel is booted on a b.L
dual-cluster system.
In bL_switcher_halve_cpus() we already have a runtime validation check
to make sure we're dealing with only two clusters, so booting on a quad
cluster system will be caught and switcher activation aborted.
However, the b.L switcher must ensure the MCPM layer is initialized on
the booted hardware before doing anything. The mcpm_is_available()
function is added to that effect.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Abhilash Kesavan <kesavan.abhilash@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
For vmcore generated by LPAE enabled kernel, user space
utility such as crash needs additional infomation to
parse.
So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
i386 linux does.
Cc: <stable@vger.kernel.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result.
When viewing ftrace record in big-endian ARM systems, we found that
the timestamp errors:
swapper-0 [001] 1325.970000: 0:120:R ==> [001] 16:120:R events/1
events/1-16 [001] 1325.970000: 16:120:S ==> [001] 0:120:R swapper
swapper-0 [000] 1325.1000000: 0:120:R + [000] 15:120:R events/0
swapper-0 [000] 1325.1000000: 0:120:R ==> [000] 15:120:R events/0
swapper-0 [000] 1326.030000: 0:120:R + [000] 1150:120:R sshd
swapper-0 [000] 1326.030000: 0:120:R ==> [000] 1150:120:R sshd
When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2".
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Cc: <stable@vger.kernel.org> # 2.6.20+
Signed-off-by: Alex Wu <wuquanming@huawei.com>
Signed-off-by: Xiangyu Lu <luxiangyu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 0406a40a0 ("ASoC: jz4740: Use the generic dmaengine PCM driver")
jz4740-pcm.c file, but neglected to remove the Makefile entries.
Fixes: 0406a40a0 ("ASoC: jz4740: Use the generic dmaengine PCM driver")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
fixup_user_fault() is used by the futex code when the direct user access
fails, and the futex code wants it to either map in the page in a usable
form or return an error. It relied on handle_mm_fault() to map the
page, and correctly checked the error return from that, but while that
does map the page, it doesn't actually guarantee that the page will be
mapped with sufficient permissions to be then accessed.
So do the appropriate tests of the vma access rights by hand.
[ Side note: arguably handle_mm_fault() could just do that itself, but
we have traditionally done it in the caller, because some callers -
notably get_user_pages() - have been able to access pages even when
they are mapped with PROT_NONE. Maybe we should re-visit that design
decision, but in the meantime this is the minimal patch. ]
Found by Dave Jones running his trinity tool.
Reported-by: Dave Jones <davej@redhat.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There were occasional ADSP crash during reboot testing:
[ 11.883364] BUG: unable to handle kernel paging request at ffffc90121700000
[ 11.883380] IP: [<ffffffffc024d8bc>] sst_module_insert_fixed_block+0x24f/0x26d [snd_soc_sst_dsp]
[ 11.883397] PGD 7800b067 PUD 0
[ 11.883405] Oops: 0002 [#1] SMP
[ 11.886418] gsmi: Log Shutdown Reason 0x03
The virtual address, ffffc90121700000, was out of range. The virtual
address is calculated by adding LPE base address with an offset:
sst_memcpy32(dsp->addr.lpe + data->offset, data->data, data->size);
The offset is calculated in sst_byt_parse_module, by subtraction of
two virtual addresses dsp->addr.fw_ext and dsp->addr.lpe:
block_data.offset = block->ram_offset + (dsp->addr.fw_ext - dsp->addr.lpe);
These virtual addresses are assigned by kernel from ioremap:
sst->addr.lpe = ioremap(pdata->lpe_base, pdata->lpe_size);
sst->addr.fw_ext = ioremap(pdata->fw_base, pdata->fw_size);
In current driver code, offset is defined as unsigned int32:
struct sst_module_data {
...
u32 offset; /* offset in FW file */
};
Most of the time kernel assigned virtual addresses with addr.fw_ext
greater than addr.lpe. But sometimes it was the other way round.
Fix the problem by declaring offset as signed int32_t.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
There is a duplicated Kconfig entry for "kernel/power/Kconfig"
in menu "Power management options" and "CPU Power Management",
remove the one from menu "CPU Power Management" suggested by
Viresh.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This fixes commit 6290b53de0 (arm64: compat: Wire up new AArch32 syscalls)
which did not update __NR_compat_syscalls accordingly.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
- Change a crucial semantic ordering in the GPIO irqchip
helpers.
- Fix two nasty regressions in the ACPI gpiolib extensions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTUQ+6AAoJEEEQszewGV1zue0P/iXpOgzTffwqS67ZtRCjHk2C
nQ5plRWLgPXJndMuuGKu38kf1HkwKbdTUAZ+tqtVe/m1kGPcv+V5XkMiPCB+nzYw
eOyMTJCPLVv485BmSlKdHLrZW8wLvq03Hs+EsKJ90YxHUYFhJNnqUkuiHqidL+eg
b/Z8Nzq2x4VSji0n4vzJKdhiSwJt4uTo9hzkC+UHylL7mM3x5/+pfRPRpbToEBCH
zitDXgcCyXLCucHeEc10e7uHXwYxdiLC8WwxK+ztnEFCK0EWWRdlSg+C0PJEnnD9
4/kEZXn69dDTSpOxgNKjGm8NLrA5FOzN7YqMuznz88RWNvtTmd3NKm7tYTlS1T4D
8BO9TJkyY8bis49Q6pwgr5J9MNdEBZimUZUjHzJYdekKxY1WBT7xPKM7CvtH2d/3
gq0qBd8HGG5fmxs6cKxgOehyOnBBMVpxTSiQmNQxPqIcz4jrtnIqVTj3zkxcb7Kf
MttAGKNf2MqIFZmRXg3TXu+KhNZsQD8oL61xNknog3TosWoLC5yQTF7HCCU+8hIz
EdOmaMoAV+K8v7mY0/KWJiKros6RNHhRUdXK/jGpNl2U5yy+Rfp9SU7jzwmv8J+O
khDKGOb2KHbc9ydzW9Ut/65Ys6oMkIbiTnwZqsdTZ/Pv2nYDOyP9L1M6ng0k1tNj
lZ34WI4WAafxZwglhLdy
=Tc0Z
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull gpio fixes from Linus Walleij:
"A small batch of GPIO fixes for the v3.15 series. I expect more to
come in but I'm a bit behind on mail, might as well get these to you
right now:
- Change a crucial semantic ordering in the GPIO irqchip helpers
- Fix two nasty regressions in the ACPI gpiolib extensions"
* tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio / ACPI: Prevent potential wrap of GPIO value on OpRegion read
gpio / ACPI: Don't crash on NULL chip->dev
gpio: set data first, then chip and handler
Pull x86 vdso fix from Peter Anvin:
"This is a single build fix for building with gold as opposed to GNU
ld. It got queued up separately and was expected to be pushed during
the merge window, but it got left behind"
* 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, vdso: Make the vdso linker script compatible with Gold
Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA. This
properly detects ATPX on those laptops.
Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com
Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.
v2: fix the vblank and vrefresh helpers as well
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We need to check whether drm_ht_create succeed and clean up
if not.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is C standard hair-splitting, but afaict
- sum will be promoted to signed int in computation since
uint8_t fits
- signed overflow is undefined.
No we need to add up an awful lot of bytes to actually make it
overflow. But I guess the real risk is gcc spotting this and going
bananas. Fix this by simply using unsigned in to force all computations
to use the well-defined unsigned behaviour.
Spotted by coverity.
v2: Simplify the entire computation as suggested by Jean.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Jean-Francois Moine <moinejf@free.fr>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Noticed while chasing coverity reports, somehow this one here was not
flagged.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to set it to -ENODEV when we don't recognize the device.
Otherwise we return/print stack garbage.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The context_dtor callback is only called once we've successfully loaded
the driver, which means dev->dev_private is set up. The check is hence
pointless.
Also dev->dev_private is deref already above, so compilers are free
to elide it anyway.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
v2: Fix patch subject.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Should be 5 rather than 4.
Noticed-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
File-private locks have been merged into Linux for v3.15, and *now*
people are commenting that the name and macro definitions for the new
file-private locks suck.
...and I can't even disagree. The names and command macros do suck.
We're going to have to live with these for a long time, so it's
important that we be happy with the names before we're stuck with them.
The consensus on the lists so far is that they should be rechristened as
"open file description locks".
The name isn't a big deal for the kernel, but the command macros are not
visually distinct enough from the traditional POSIX lock macros. The
glibc and documentation folks are recommending that we change them to
look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
programmer will typo one of the commands wrong, and also makes it easier
to spot this difference when reading code.
This patch makes the following changes that I think are necessary before
v3.15 ships:
1) rename the command macros to their new names. These end up in the uapi
headers and so are part of the external-facing API. It turns out that
glibc doesn't actually use the fcntl.h uapi header, but it's hard to
be sure that something else won't. Changing it now is safest.
2) make the the /proc/locks output display these as type "OFDLCK"
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Carlos O'Donell <carlos@redhat.com>
Cc: Stefan Metzmacher <metze@samba.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Frank Filz <ffilzlnx@mindspring.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Daniel Vetter
Russell King
Paulo Zanoni
Jordan Rife
Lejun Zhu
Greg Kroah-Hartman
Dave Airlie
Victor Kamensky
Nicolas Pitre
Liu Hua
Xiangyu Lu
Mark Brown
Lars-Peter Clausen
Linus Torvalds
Wenkai Du
Hanjun Guo
Miklos Szeredi
Alex Deucher
Jeff Layton