i915_driver_load adds a write-combining MTRR region for the GTT
aperture to improve memory speeds through the aperture. If
i915_driver_load fails after this, it would not have cleaned up the
MTRR. This shouldn't cause any problems, except for consuming an MTRR
register. Still, it's best to clean up completely in the failure path,
which is easily done by calling mtrr_del if the mtrr was successfully
allocated.
i915_driver_load calls i915_gem_load which register
i915_gem_inactive_shrink. If i915_driver_load fails after calling
i915_gem_load, the shrinker will be left registered. When called, it
will access freed memory and crash. The fix is to unregister the shrinker in the
failure path using code duplicated from i915_driver_unload.
i915_driver_load also has some incorrect gotos in the error cleanup
paths:
* After failing to initialize the GTT (which cannot happen, btw,
intel_gtt_get returns a fixed (non-NULL) value), it tries to
free the uninitialized WC IO mapping. Fixed this by changing the
target from out_iomapfree to out_rmmap
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Lin Ming <ming.m.lin@intel.com>
Using integer variable types for register to data conversions can cause
overflows especially for power calculations, which are in microwatt.
Use long variables instead.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.39+
BUS_CNTL reg and bits moved between pre-PCIE and PCIE asics.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Skip connectors that do not have an HPD pin.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=39027
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
SLIP6 have nothing to do with CSLIP so placing a block of
SLIP6-related code within a CSLIP ifdef-endif block is incorrect.
Signed-off-by: Ilya Matvejchikov <matvejchikov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c
files, and I need it in a third one to fix a powerpc bug, so let's
first move it into a header
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
The nuvoton-cir inherited an insanely low idle timeout value from the
mceusb driver. We're fixing mceusb, should fix this driver too.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This matches the typical timeout advertised by hardware, once we're
actually interpreting it correctly.
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Unit missmatch in mceusb_handle_command. It should be converting to us,
not 1/10th of ms.
mceusb_dev_printdata 100us/ms -> 1000us/ms
Alter format of fix slightly and update comment to match proper reality.
Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts commit e38030f3ff.
MSI flat-out doesn't work right on cx2388x devices yet. There are now
multiple reports of cards that hard-lock systems when MSI is enabled,
including my own HVR-1250 when trying to use its built-in IR receiver.
Disable MSI and it works just fine. Similar for another user's HVR-1270.
Issues have also been reported with the HVR-1850 when MSI is enabled,
and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
seen with an 1800.
CC: stable@kernel.org
CC: Steven Toth <stoth@kernellabs.com>
CC: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] msp3400: fill in v4l2_tuner based on vt->type field
[media] tuner-core.c: don't change type field in g_tuner or g_frequency
[media] cx18/ivtv: fix g_tuner support
[media] tuner-core: power up tuner when called with s_power(1)
[media] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEK
[media] tuner-core: simplify the standard fixup
[media] tuner-core/v4l2-subdev: document that the type field has to be filled in
[media] v4l2-subdev.h: remove unused s_mode tuner op
[media] feature-removal-schedule: change in how radio device nodes are handled
[media] bttv: fix s_tuner for radio
[media] pvrusb2: fix g/s_tuner support
[media] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner
[media] tuner-core: fix tuner_resume: use t->mode instead of t->type
[media] tuner-core: fix s_std and s_tuner
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86:
hp-wmi: fix use after free
dell-laptop - using buffer without mutex_lock
Revert: "dell-laptop: Toggle the unsupported hardware killswitch"
platform-drivers-x86: set backlight type to BACKLIGHT_PLATFORM
thinkpad-acpi: handle HKEY 0x4010, 0x4011 events
drivers/platform/x86: Fix memory leak
thinkpad-acpi: handle some new HKEY 0x60xx events
acer-wmi: fix bitwise bug when set device state
acer-wmi: Only update rfkill status for associated hotkey events
[ 191.310008] WARNING: kmemcheck: Caught 32-bit read from freed memory (f0d25f14)
[ 191.310011] c056d2f088000000105fd2f00000000050415353040000000000000000000000
[ 191.310020] i i i i f f f f f f f f f f f f f f f f f f f f f f f f f f f f
[ 191.310027] ^
[ 191.310029]
[ 191.310032] Pid: 737, comm: modprobe Not tainted 3.0.0-rc5+ #268 Hewlett-Packard HP Compaq 6005 Pro SFF PC/3047h
[ 191.310036] EIP: 0060:[<f80b3104>] EFLAGS: 00010286 CPU: 0
[ 191.310039] EIP is at hp_wmi_perform_query+0x104/0x150 [hp_wmi]
[ 191.310041] EAX: f0d25601 EBX: f0d25f00 ECX: 000121cf EDX: 000121ce
[ 191.310043] ESI: f0d25f10 EDI: f0f97ea8 EBP: f0f97ec4 ESP: c173f34c
[ 191.310045] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 191.310046] CR0: 8005003b CR2: f540c000 CR3: 30f30000 CR4: 000006d0
[ 191.310048] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 191.310050] DR6: ffff4ff0 DR7: 00000400
[ 191.310051] [<f80b317b>] hp_wmi_dock_state+0x2b/0x40 [hp_wmi]
[ 191.310054] [<f80b6093>] hp_wmi_init+0x93/0x1a8 [hp_wmi]
[ 191.310057] [<c10011f0>] do_one_initcall+0x30/0x170
[ 191.310061] [<c107ab9f>] sys_init_module+0xef/0x1a60
[ 191.310064] [<c149f998>] sysenter_do_call+0x12/0x28
[ 191.310067] [<ffffffff>] 0xffffffff
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
This reverts commit a3d77411e8,
as it causes a mess in the wireless rfkill status on some models.
It is probably a bad idea to toggle the rfkill for all dell models
without the respect to the claim that it is hardware-controlled.
Cc: stable@kernel.org
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Patch 2e711c04db
(PM: Remove sysdev suspend, resume and shutdown operations)
deleted sysdev_suspend(), which was being relied on to call
check_wakeup_irqs() in suspend. If check_wakeup_irqs() is not
called, wake interrupts that are pending when suspend is
entered may be lost. It also breaks IRQCHIP_MASK_ON_SUSPEND,
which is handled in check_wakeup_irqs().
This patch adds a call to check_wakeup_irqs() in syscore_suspend(),
similar to what was deleted in sysdev_suspend().
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
I came across a memory leak during a cyclic cpu-online-offline test.
Signed-off-by: Yu Luming <luming.yu@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:
hwmon: (pmbus) Improve auto-detection of temperature status register
hwmon: (lm95241) Fix negative temperature results
hwmon: (lm95241) Fix chip detection code
It is possible that a PMBus device supports the READ_TEMPERATURE2 and/or
READ_TEMPERATURE3 registers but does not support READ_TEMPERATURE1.
Improve temperature status register detection to address this condition.
Reported-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.39+
Negative temperatures were returned in degrees C instead of milli-Degrees C.
Also, negative temperatures were reported for remote temperature sensors even
if the chip was configured for positive-only results.
Fix by detecting temperature modes, and by treating negative temperatures
similar to positive temperatures, with appropriate sign extension.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.30+
* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: 6994/1: smp_twd: Fix typo in 'twd_timer_rate' printing
ARM: 6987/1: l2x0: fix disabling function to avoid deadlock
ARM: 6966/1: ep93xx: fix inverted RTS/DTR signals on uart1
ARM: 6980/1: mmci: use StartBitErr to detect bad connections
ARM: 6979/1: mach-vt8500: add forgotten irq_data conversion
ARM: move memory layout sanity checking before meminfo initialization
ARM: 6990/1: MAINTAINERS: add entry for ARM PMU profiling and debugging
ARM: 6989/1: perf: do not start the PMU when no events are present
ARM: dmabounce: fix map_single() error return value
When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
"Register access failure" is logged and an interrupt storm or a kernel
panic happens. https://bugzilla.kernel.org/show_bug.cgi?id=36622
Until this is sorted out (if that is going to succeed at all), let's
just prevent firewire-ohci from touching these devices.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
* 's5p-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: S3C2440: fix section mismatch on mini2440
ARM: S3C24XX: drop return codes in void function of dma.c
ARM: S3C24XX: don't use uninitialized variable in dma.c
ARM: EXYNOS4: Set appropriate I2C device variant
ARM: S5PC100: Fix for compilation error
spi/s3c64xx: Bug fix for SPI with different FIFO level
ARM: SAMSUNG: Add tx_st_done variable
ARM: EXYNOS4: Address a section mismatch w/ suspend issue.
ARM: S5P: Fix bug on init of PWMTimers for HRTimer
ARM: SAMSUNG: header file revised to prevent declaring duplicated
ARM: EXYNOS4: fix improper gpio configuration
ARM: EXYNOS4: Fix card detection for sdhci 0 and 2
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
regulator: max8997: Fix setting inappropriate value for ramp_delay variable
regulator: db8500-prcmu: small fixes
regulator: max8997: remove dependency on platform_data pointer
regulator: MAX8997: Fix for divide by zero error
regulator: max8952 - fix wrong gpio valid check
This driver handles the variants pca9530-pca9533, so it chose the name
"pca953x". However, there is a gpio driver which decided on the same
name. As a result, those two can't be loaded at the same time. Add a
subsystem prefix to make the driver name unique. Device matching will not
suffer, because both are I2C drivers which match using a
i2c_device_id-table which is not altered.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes a regression in 3.0 reported by Paul Parsons regarding the
removal of the msleep(1) in the ds1wm_reset() function:
: The linux-3.0-rc4 DS1WM 1-wire driver is logging "bus error, retrying"
: error messages on an HP iPAQ hx4700 PDA (XScale-PXA270):
:
: <snip>
: Driver for 1-wire Dallas network protocol.
: DS1WM w1 busmaster driver - (c) 2004 Szabolcs Gyurko
: 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko
: ds1wm ds1wm: pass: 1 bus error, retrying
: ds1wm ds1wm: pass: 2 bus error, retrying
: ds1wm ds1wm: pass: 3 bus error, retrying
: ds1wm ds1wm: pass: 4 bus error, retrying
: ds1wm ds1wm: pass: 5 bus error, retrying
: ...
:
: The visible result is that the battery charging LED is erratic; sometimes
: it works, mostly it doesn't.
:
: The linux-2.6.39 DS1WM 1-wire driver worked OK. I haven't tried 3.0-rc1,
: 3.0-rc2, or 3.0-rc3.
This sleep should not be required on normal circuitry provided the
pull-ups on the bus are correctly adapted to the slaves. Unfortunately,
this is not always the case. The sleep is restored but as a parameter to
the probe function in the pdata.
[akpm@linux-foundation.org: coding-style fixes]
Reported-by: Paul Parsons <lost.distance@yahoo.com>
Tested-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Jean-François Dagenais <dagenaisj@sonatest.com>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The LM95241 driver accepts every chip ID equal to or larger than 0xA4 as its
own, and other chips such as LM95245 use chip IDs in the accepted ID range.
This results in false chip detection.
Fix problem by accepting only the known LM95241 chip ID.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org # 2.6.30+
Multiple attempts to dynamically reallocate pci resources have
unfortunately lead to regressions. Though we continue to fix the
regressions and fine tune the dynamic-reallocation behavior, we have not
reached a acceptable state yet.
This patch provides a interim solution. It disables dynamic reallocation
by default, but adds the ability to enable it through pci=realloc kernel
command line parameter.
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The ramp_delay variable can be set lower than the desired value.
This patch fixes it.
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: KyungMin Park <kyungmin.park@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Small cleanups for better readability.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
The platform_data (pdata) may be pointing to __initdata section, which
may be free'd from the memory. The dependency on pdata in non-init
functions is removed in this patch to allow platform to declare
__initdata for platform data.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Currently, ramp_delay variable is used uninitialzed in
max8997_set_voltage_ldobuck which gets called through
regulator_register calls.
To fix the problem, in max8997_pmic_probe, ramp_delay initialization
code is moved before calls to regulator_register.
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
evergreen+ asics have 2-6 crtcs. Don't access crtc registers
for crtc regs that don't exist as they have very high latency
and may cause problems on some asics. The previous code missed
a few cases and was not fine grained enough (missed the 4 crtc
case for example).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38800
v2: fix typo noticed by Chris Bandy <cbandy@jbandy.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Tested-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The third parameter of module_param is supposed to represent sysfs
file permissions. A value of "1" leads to the following:
$ ls -l /sys/module/natsemi/parameters/
total 0
---------x 1 root root 4096 Jul 8 09:46 dspcfg_workaround
I am changing it to "0" to align with the other module parameters in
this driver.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Tim Hockin <thockin@hockin.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/kms: allow drm_mode_group with no objects
drm/radeon/kms: free ib pool on module unloading
drm/radeon/kms: fix typo in evergreen disp int status register
drm/radeon/kms: fix typo in IH_CNTL swap bitfield
The wrong bit was masked when acking langwell gpio interrupts.
Reason for maskig the wrong bit was probably because__ffs() and ffs() functions
return bit indexes differently (0..31 vs 1..32)
This fixes langwell based devices from hanging when a gpio interrupt is
triggered and undoes the breakage which occurred in change set
732063b92b
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* 'for-30-rc5/all-i2c' of git://git.fluff.org/bjdooks/linux:
i2c-bfin-twi: abort transfer is MEM bit is reset unexpectedly
i2c-s3c2410: Remove useless break code
i2c-s3c2410: Fix typo 'i2s' -> 'i2c'
i2c: tegra: Assign unused slave address
According to the hardware documentation, GDRST is exactly the same as on
Sandybridge. So simply enable the existing code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
On sinks with a DPCD rev of 1.1 or greater, we can send sink power
management commands to address 0x600 per section 5.1.5 of the
DisplayPort 1.1a spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When checking link status during a hot plug event or detecting sink
presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a
DisplayPort spec). Consolidate the retry code into a
native_aux_read_retry function for use by get_link_status and _detect.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We currently use this when a hot plug event is received, only checking
the link status and re-training if we had previously configured a link.
However if we want to preserve the DP configuration across both hot plug
and DPMS events (which we do for userspace apps that don't respond to
hot plug uevents), we need to unconditionally check the link and try to
bring it up on hot plug.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If ->detect is called too soon after a hot plug event, the sink may not
be ready yet. So try up to 3 times with 1ms sleeps in between tries to
get the data (spec dictates that receivers must be ready to respond within
1ms and that sources should try 3 times).
See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When a hotplug event is received, we need to check the receiver cap bits
in case they've changed (as they might with a hub or chain config).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Makes it easier to search for DP related constants.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Especially after a hotplug or power status change, the sink may not
reply immediately to a link status query. So retry 3 times per the spec
to really make sure nothing is there.
See section 9.1 of the 1.1a DisplayPort spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit e534c5b831 (USB: fix regression
occurring during device removal) didn't go far enough. It failed to
take into account that when a driver claims multiple interfaces, it may
release them all at the same time. As a result, some interfaces can
get released before they are unregistered, and we deadlock trying to
acquire the bandwidth_mutex that we already own.
This patch (asl478) handles this case by setting the "unregistering"
flag on all the interfaces before removing any of them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Tested-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The vt->type field determines how the msp3400 should fill in the
tuner data, not whether the msp3400 is in radio mode or not.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'for-linus' of git://git.kernel.dk/linux-block:
drbd: we should write meta data updates with FLUSH FUA
drbd: fix limit define, we support 1 PiByte now
drbd: when receive times out on meta socket, also check last receive time on data socket
drbd: account bitmap IO during resync as resync-(related-)-io
drbd: don't cond_resched_lock with IRQs disabled
drbd: add missing spinlock to bitmap receive
drbd: Use the correct max_bio_size when creating resync requests
cfq-iosched: make code consistent
cfq-iosched: fix a rcu warning
The tuner core should not silently change the type field in g_tuner and
g_frequency. If the tuner is in a different mode than the one that was
requested, then just fill in what you can and don't attempt to read afc,
signal or rxsubchans values.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (31 commits)
sctp: fix missing send up SCTP_SENDER_DRY_EVENT when subscribe it
net: refine {udp|tcp|sctp}_mem limits
vmxnet3: round down # of queues to power of two
net: sh_eth: fix the parameter for the ETHER of SH7757
net: sh_eth: fix cannot work half-duplex mode
net: vlan: enable soft features regardless of underlying device
vmxnet3: fix starving rx ring whenoc_skb kb fails
bridge: Always flood broadcast packets
greth: greth_set_mac_add would corrupt the MAC address.
net: bind() fix error return on wrong address family
natsemi: silence dma-debug warnings
net: 8139too: Initial necessary vlan_features to support vlan
Fix call trace when interrupts are disabled while sleeping function kzalloc is called
qlge:Version change to v1.00.00.29
qlge: Fix printk priority so chip fatal errors are always reported.
qlge:Fix crash caused by mailbox execution on wedged chip.
xfrm4: Don't call icmp_send on local error
ipv4: Don't use ufo handling on later transformed packets
xfrm: Remove family arg from xfrm_bundle_ok
ipv6: Don't put artificial limit on routing table size.
...
The driver shouldn't override vt->type, and the tuner name should be
based on vt->type as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers must be able to rely on s_power to power up subdevices.
Note that at this moment no driver attempts to power up tuners. This probably
isn't surprising since s_power(1) was never implemented in tuner-core.c until
now.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Prohibit attempts to change the tuner to a type that is different
from the device node the ioctl is called from. I.e. the type must
be RADIO for a radio node and ANALOG_TV for a video/vbi node.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The tuner ops g_frequency, g_tuner and s_tuner require that the tuner type
field is filled in. Document this.
The tuner-core doc is based on a patch from Mauro Carvalho Chehab <mchehab@redhat.com>.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix typo: g_tuner should have been s_tuner.
Tested with a bttv card.
Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.
Tested with my pvrusb2.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Mike Isely <isely@pobox.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The subdevs are supposed to receive a valid tuner type for the g_frequency
and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
this in v4l2-ioctl.c based on whether the device node from which this is
called is a radio node or not.
The spec does not require applications to fill in the type, and if they
leave it at 0 then the 'check_mode' call in tuner-core.c will return
an error and the ioctl does nothing.
Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
set_mode is called with t->type, which is the tuner type. Instead, use
t->mode which is the actual tuner mode (i.e. radio vs tv).
Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std/s_tuner
first calls set_mode, and if that returns 0 (i.e. the mode is supported)
then they set t->std/t->audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Cc: stable@kernel.org
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some newly added drivers do not set backlight type, as a result
/sys/class/backlight/<backlight>/type shows incorrect backlight type.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Yin Kangkai <kangkai.yin@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Handle events 0x4010 and 0x4011 so that we do not pester users about them.
These events report when the thinkpad is docked/undocked to a native
hotplug dock (i.e. one that does not need ACPI handling, nor is represented
in the ACPI device tree). Such docks are based on USB 2.0/3.0, and also
work as port replicators.
We really want a proper dock class to report these, or at least new input
EV_SW events. Since it is not clear which one to use yet, keep reporting
them as vendor-specific ThinkPad events.
WARNING: As defined by the thinkpad-acpi sysfs ABI rules of engagement, the
vendor-specific events will be REMOVED as soon as generic events are made
available (duplicate events are a big problem), with an appropriate update
to the thinkpad-acpi sysfs/event ABI versioning. Userspace is already
prepared to provide easy backwards compatibility for such changes when
convenient to the distro (see acpi-fakekey).
* Event 0x4010: docking to hotplug dock/port replicator
* Event 0x4011: undocking from hotplug dock/port replicator
Typical usecase would be to trigger display reconfiguration.
Reports mention T410, T510, and series 3 docks/port replicators. Special
thanks to Robert de Rooy for his extensive report and analysis of the
situation.
http://www.thinkwiki.org/wiki/ThinkPad_Port_Replicator_Series_3http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Series_3http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3_for_Mobile_Workstationshttp://lenovoblogs.com/insidethebox/?p=290
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reported-by: Claudius Hubig <claudiushubig@chubig.net>
Reported-by: Doctor Bill <docbill@gmail.com>
Reported-by: Korte Noack <gbk.noack@gmx.de>
Reported-by: Robert de Rooy <robert.de.rooy@gmail.com>
Reported-by: Sebastian Will <swill@csail.mit.edu>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
data is not freed in the error case of
compal_probe().
Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Handle some user interface events from the newer Lenovo models. We are likely
to do something smart with these events in the future, for now, hide the ones
we are already certain about from the user and userspace both.
* Events 0x6000 and 0x6005 are key-related. 0x6005 is not properly identified
yet. Ignore these events, and do not report them.
* Event 0x6040 has not been properly identified yet, and we don't know if it
is important (looks like it isn't, but still...). Keep reporting it.
* Change the message the driver outputs on unknown 0x6xxx events, as all
recent events are not related to thermal alarms. Degrade log level from
ALERT to WARNING.
Thanks to all users who reported these events or asked about them in a number
of mailing lists. Your help is highly appreciated, even if I did took a lot of
time to act on them. For that I apologise.
I will list those that identified the reasons for the events as "reported-by",
and I apologise in advance if I leave anyone out: it was not done on purpose, I
made the mistake of not properly tagging all event report emails separately,
and might have missed some.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Markus Malkusch <markus@malkusch.de>
Reported-by: Peter Giles <g1l3sp@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Fix a bitwise bug that was found by Joern Heissler, it must be OR
but not AND when we query current device state.
Acked-by: Joern Heissler <linux-acpi@joern.heissler.de>
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Thomas Renninger <trenn@suse.de>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
acer-wmi is indiscriminately using the device state from hotkey
events to update the various rfkill states. On the Aspire 1830 this
can result in a soft block on the wlan when the touchpad hotkey is
pressed, as it is reporting a non-zero device state that does not
reflect the wireless status. To fix this, only update rfkill states
when a wlan or bluetooth hotkey is pressed.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Sometimes we could be controlling a device (such as an NVIDIA Tesla) that
has no crtcs/encoders/connectors.
One could argue that the driver should unset DRIVER_MODESET in this case,
but that changes a whole heap of the DRM's other behaviours, and it's much
easier to just be a modesetting driver without any outputs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ib pool weren't free for various newer asic on module unload.
This doesn't cause much arm but still could be candidate for
stable.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
cc: stable@kernel.org
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
vmxnet3 device supports only power-of-two number of queues. The driver
therefore needs to check this and rounds down the number of queues to the
nearest power of two.
Signed-off-by: Yong Wang <yongwang@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Reviewed-by: Dmitry Torokhov <dtor@vmware.com>
Stresstesting insert/remove of SD-cards can trigger
a StartBitErr. This made the driver to hang in forever
waiting for a non ocurring data timeout.
This bit and interrupt is documented in the original
PL180 TRM, just never implemented until now.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: Linus Walleij <linus.walleij@stericsson.com>
Reviewed-by: Jonas Aberg <jonas.aberg@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (46 commits)
[media] rc: call input_sync after scancode reports
[media] imon: allow either proto on unknown 0xffdc
[media] imon: auto-config ffdc 7e device
[media] saa7134: fix raw IR timeout value
[media] rc: fix ghost keypresses with certain hw
[media] [staging] lirc_serial: allocate irq at init time
[media] lirc_zilog: fix spinning rx thread
[media] keymaps: fix table for pinnacle pctv hd devices
[media] ite-cir: 8709 needs to use pnp resource 2
[media] V4L: mx1-camera: fix uninitialized variable
[media] omap_vout: Added check in reqbuf & mmap for buf_size allocation
[media] OMAP_VOUT: Change hardcoded device node number to -1
[media] OMAP_VOUTLIB: Fix wrong resizer calculation
[media] uvcvideo: Disable the queue when failing to start
[media] uvcvideo: Remove buffers from the queues when freeing
[media] uvcvideo: Ignore entities for terminals with no supported format
[media] v4l: Don't access media entity after is has been destroyed
[media] media: omap3isp: fix a potential NULL deref
[media] media: vb2: fix allocation failure check
[media] media: vb2: reset queued_count value during queue reinitialization
...
Fix up trivial conflict in MAINTAINERS as per Mauro
If the driver didn't set this parameter on the ETHER, the CPU will
encounter the "data address error" exception.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When link was down, the bit of DM in ECMR was always set.
So, we could not use half-duplex mode on the controller.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The existing macro fails for following scenarios.
1) S5P64X0 channel 1
2) S5PV210 channel 1
The FIFO data level supported in the above SoCs either 64 or
256 bytes depending on the channel. Because of this the TX_DONE
is the 25 bit in the status register.
The existing macro works for the following scenarios
1) S3C6410 all channels
2) S5PC100 all channels
The FIFO data level supported in the above SoCs 64 bytes
on all the channels. Because of this the TX_DONE is the 21 bit
in the status register.
So when we use the existing macro for the non-working SoCs
it is not anding with the TX_DONE bit for transmission status check.
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: fix regression occurring during device removal
USB: fsl_udc_core: fix build breakage when building for ARM arch
If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.
This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Reported-by: Mark Davis
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
