The logic of temperature fault flags is wrong, it shows faults when
there are none and vice versa. Fix it.
I can't believe this has been broken since the driver was added, 8
months ago, basically breaking temp1 and temp3, and nobody ever
complained.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Avoid registering channels that have zero divider settings in them, as this
will only lead to kernel OOPS from divide-by-zero when the sysfs entry is
read.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
If ret is unsigned, the checks for negative wm831x_reg_read() return values
are wrong. The error value should be transmitted to its caller, e.g.
wm831x_gp_ldo_get_status() which tests for a negative return value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
In the NAPI poll function(emac_poll), check for netif_running()
is unnecassary. In addition to associated runtime overhead, it
also results in a continuous softirq loop when the interface is
brought down under heavy traffic(tested wit Traffic Generator).
Once the interface is disabled, the poll function always returns
zero(with the check for netif_running) and napi_complete() would
never get called resulting in softirq loop.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the NAPI poll function, check for netif_running() is unnecassary.
In addition to associated runtime overhead, it also results in
continuous softirq loop when the interface is brought down under heavy
traffic(tested with Traffic Generator).Once the interface is disabled,
the poll function always returns zero(with the check for netif_running)
and napi_complete() would never get called resulting in softirq loop.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The returned error should stay negative
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Karsten Keil <keil@b1-systems.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the existing random_ether_addr() to generate random MAC
instead of doing it by-hand.
Signed-off-by: Stanislav O. Bezzubtsev <stas@lvk.cs.msu.su>
Signed-off-by: David S. Miller <davem@davemloft.net>
The version string already contains the printk level
specifying it again results in the following message
being printed:
<6>r6040: RDC R6040 NAPI ...
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.infradead.org/users/dwmw2/iommu-2.6.32:
intel-iommu: Support PCIe hot-plug
intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough
intel-iommu: Check for 'DMAR at zero' BIOS error earlier.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: psmouse - remove unneeded '\n' from psmouse.proto parameter
Input: atkbd - restore LED state at reconnect
Input: force LED reset on resume
Input: fix locking in memoryless force-feedback devices
* 'for-linus' of git://neil.brown.name/md:
md/raid5: Allow dirty-degraded arrays to be assembled when only party is degraded.
Don't unconditionally set in_sync on newly added device in raid5_reshape
md: allow v0.91 metadata to record devices as being active but not in-sync.
md: factor out updating of 'recovery_offset'.
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
[S390] s390: fix single stepping on svc0
[S390] sclp: undo quiesce handler override on resume
[S390] reset cputime accounting after IPL from NSS
[S390] monreader: fix use after free bug with suspend/resume
If the waker is killed before it can replay outstanding URBs, these URBs
won't be freed or will be replayed at the next open. This patch closes
the window by explicitely discarding outstanding URBs.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.
For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22
Bug:
driver for all MTU up to 1536 use receive buffer size 1536
As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.
Example:
host_good> ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good> ping host_r8169
Ok
host_good> ping -s 1500 host_r8169
Fail
host_good> ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good> ping -s 1500 host_r8169
Ok
Bonus: got rid of magic number 8
Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the missing "get_xstats_size" callback for the
netlink interface, which is required if "fill_xstats" is used,
as pointed out by Patrick McHardy.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In 2.6.32-rc the new EMS USB CAN driver was contributed and added the Kconfig
entry right behind an entry of the same *vendor*. This teared the SJA1000
based driver selection into pieces.
This fix cleans up the 2.6.32-rc Kconfig files for the CAN drivers and moves
the SJA1000 and USB Kconfig portions into the belonging directories.
As there are many new CAN drivers in the queue getting this cleanup into
2.6.32-rc would massively reduce the problems for the upcoming drivers.
Thanks,
Oliver
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due commit 4b77b0a2ba, it is not more
possible to pci_restore_state() more than once without calling
pci_save_state() in the middle.
Actually running a ethtool test on s2io makes the card inactive,
and it needs to unload/reload the module to fix.
This patch just save the state just after it restore in order to
keep the old behaviour
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit b8ecd988b1.
Due to poor API call balancing by me, this commit not only broke ipw2200
if it can't find it's firmware, it broke ipw2100 basically anytime you
removed the module. At this point in the cycle, let's just put it back
to a sane state and try again next time...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In a system where the ctrl-alt-del init action initiated by signal
quiesce suspends the machine the quiesce handler override for
_machine_restart, _machine_halt and _machine_power_off needs to be
undone, otherwise the override is still present in the resumed
system. The next shutdown would then load the quiesce state psw
instead of performing the correct shutdown action.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The monreader device driver doesn't set dev->driver_data to NULL after
freeing the corresponding data structure. This leads to a use after
free bug in the freeze/thaw suspend/resume functions after the device
has been opened and closed once. Fix this by clearing dev->driver_data
in the close() function.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The get parameter function should return a string without a life-feed.
Otherwise you'll see additional empty line in sysfs parameters file.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Even though input core tells us to restore LED state and repeat rate
at resume keyboard may be reconnected either by request from userspace
(via sysfs) or just by pulling it from the box and plugging it back in.
In these cases we still need to restore state ourselves.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
We should be sending EV_LED event down to drivers upon resume even in cases
when in-kernel state of the LED is off since device could come up with some
leds turned on.
Reported-and-tested-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Normally is it not safe to allow a raid5 that is both dirty and
degraded to be assembled without explicit request from that admin, as
it can cause hidden data corruption.
This is because 'dirty' means that the parity cannot be trusted, and
'degraded' means that the parity needs to be used.
However, if the device that is missing contains only parity, then
there is no issue and assembly can continue.
This particularly applies when a RAID5 is being converted to a RAID6
and there is an unclean shutdown while the conversion is happening.
So check for whether the degraded space only contains parity, and
in that case, allow the assembly.
Signed-off-by: NeilBrown <neilb@suse.de>
When a reshape finds that it can add spare devices into the array,
those devices might already be 'in_sync' if they are beyond the old
size of the array, or they might not if they are within the array.
The first case happens when we change an N-drive RAID5 to an
N+1-drive RAID5.
The second happens when we convert an N-drive RAID5 to an
N+1-drive RAID6.
So set the flag more carefully.
Also, ->recovery_offset is only meaningful when the flag is clear,
so only set it in that case.
This change needs the preceding two to ensure that the non-in_sync
device doesn't get evicted from the array when it is stopped, in the
case where v0.90 metadata is used.
Signed-off-by: NeilBrown <neilb@suse.de>
This is a combination that didn't really make sense before.
However when a reshape is converting e.g. raid5 -> raid6, the extra
device is not fully in-sync, but is certainly active and contains
important data.
So allow that start to be meaningful and in particular get
the 'recovery_offset' value (which is needed for any non-in-sync
active device) from the reshape_position.
Signed-off-by: NeilBrown <neilb@suse.de>
PPS events must be recorded according to PPS's mode settings.
If a process asks for (i.e.) capture-assert events only, when the PPS
client calls the pps_event() function to save the current PPS event, we
should verify the event type and then discard unwanted ones.
Also, without this patch userland processes waiting for a specific PPS
event (assert or clear but not both) may be awakened at wrong time.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: William S. Brasher <billb958@door.net>
Tested-by: Reg Clemens <clemens@dwf.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Userland programs may read/write PPS parameters at same time and these
operations may corrupt PPS data.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Reg Clemens <clemens@dwf.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
TASK_INTERRUPTIBLE and friends are now only available after including
<linux/sched.h>, so include it when needed.
bus_id is no longer available/necessary, so remove that.
Android pmem driver is not available in mainline, so remove its hooks
from drivers/video.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case of failure, device_create() returns not NULL but the error code.
The current code checks for non-NULL though which causes kernel oops in
sysfs_create_group() when device_create() fails. Check for error using
IS_ERR() and propagate the error value using PTR_ERR() instead of fixed
-ENODEV code returned now...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
v3020_mmio_read_bit() always returns 0 when left_shift > 7.
v3020_mmio_read_bit()'s return type is (unsigned char). The code returns
a value masked by (1 << left_shift) that is casted to the return type. If
left_shift is larger than 7, the cast will always result in a 0 return
value. The problem was discovered with left_shift = 16, and the included
patch corrects the problem.
The bug was introduced in the last (Apr 3 2009) commit of the file, kernel
versions 2.6.30 and later.
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Raphael Assenat <raph@8d.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/rtc/rtc-vr41xx.c: In function 'vr41xx_rtc_irq_set_freq':
drivers/rtc/rtc-vr41xx.c:217: warning: comparison of distinct pointer types lacks a cast
drivers/rtc/rtc-vr41xx.c:217: warning: right shift count >= width of type
drivers/rtc/rtc-vr41xx.c:217: warning: passing argument 1 of '__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35: note: expected 'uint64_t *' but argument is of type 'long unsigned int *'
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The config FB_PRE_INIT_FB entry in drivers/video/Kconfig pushes all entries
below it out of the menuconfig selection. Fix this.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This seems to be a different model (with a different PCI ID) than the
"Quatro" card that is also in the list.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
struct uart_port::iobase is unsigned long, so use %lx as printk format
specifier.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to Documentation/rtc.txt, RTC_WKALM_SET sets the alarm time and
enables/disables the alarm. We implement RTC_WKALM_SET through
pcf50633_rtc_set_alarm. The enabling/disabling part was missing.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
Reported-by: Michael 'Mickey' Lauer <mickey@openmoko.org>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Balaji Rao <balajirrao@openmoko.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The PCF50633 stores a month value of 1-12, but the kernel wants 0-11.
Signed-off-by: Rask Ingemann Lambertsen <rask@sygehus.dk>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Balaji Rao <balajirrao@openmoko.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
at91sam9g45 non ES lots have an alternate pixel clock calculation formula.
Introduce this one with condition on the cpu_is_xxxxx() macros.
Newer 9g45 SOC will not have good pixel clock calculation without this
fix.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix wrong bit mask for blanking register. Due to the error a CRT monitor
blanks off due to wrong frequency (out of range) instead of PM signal
(vertical and horizontal frequencies cut off).
Just compare the mask with bits set in the switch(blank) clause below the
changed line.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove fb_save_state() and fb_restore_state operations from frame buffer layer.
They are used only in two drivers:
1. savagefb - and cause bug #11248
2. uvesafb
Usage of these operations is misunderstood in both drivers so kill these
operations, fix the bug #11248 and avoid confusion in the future.
Tested on Savage 3D/MV card and the patch fixes the bug #11248.
The frame buffer layer uses these funtions during switch between graphics
and text mode of the console, but these drivers saves state before
switching of the frame buffer (in the fb_open) and after releasing it (in
the fb_release). This defeats the purpose of these operations.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11248
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Reported-by: Jochen Hein <jochen@jochen.org>
Tested-by: Jochen Hein <jochen@jochen.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michal Januszewski <spock@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
To support PCIe hot plug in IOMMU, we register a notifier to respond to device
change action.
When the notifier gets BUS_NOTIFY_UNBOUND_DRIVER, it removes the device
from its DMAR domain.
A hot added device will be added into an IOMMU domain when it first does IOMMU
op. So there is no need to add more code for hot add.
Without the patch, after a hot-remove, a hot-added device on the same
slot will not work.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The model for IOMMU passthrough is that decent devices that can cope
with DMA to all of memory get passthrough; crappy devices with a limited
dma_mask don't -- they get to use the IOMMU anyway.
This is done on the basis that IOMMU passthrough is usually wanted for
performance reasons, and it's only the decent PCI devices that you
really care about performance for, while the crappy 32-bit ones like
your USB controller can just use the IOMMU and you won't really care.
Unfortunately, the check for this was only looking at dev->dma_mask, not
at dev->coherent_dma_mask. And some devices have a 32-bit
coherent_dma_mask even though they have a full 64-bit dma_mask.
Even more unfortunately, fixing that simple oversight would upset
certain broken HP devices. Not only do they have a 32-bit
coherent_dma_mask, but they also have a tendency to do stray DMA to
unmapped addresses. And then they die when they take the DMA fault they
so richly deserve.
So if we do the 'correct' fix, it'll mean that affected users have to
disable IOMMU support completely on "a large percentage of servers from
a major vendor."
Personally, I have little sympathy -- given that this is the _same_
'major vendor' who is shipping machines which claim to have IOMMU
support but have obviously never _once_ booted a VT-d capable OS to do
any form of QA. But strictly speaking, it _would_ be a regression even
though it only ever worked by fluke.
For 2.6.33, we'll come up with a quirk which gives swiotlb support
for this particular device, and other devices with an inadequate
coherent_dma_mask will just get normal IOMMU mapping.
The simplest fix for 2.6.32, though, is just to jump through some hoops
to try to allocate coherent DMA memory for such devices in a place that
they can reach. We'd use dma_generic_alloc_coherent() for this if it
existed on IA64.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Each device has its own 'recovery_offset' showing how far
recovery has progressed on the device.
As the only real significance of this is that fact that it can
be stored in the metadata and recovered at restart, and as
only 1.x metadata can do this, we were only updating
'recovery_offset' to 'curr_resync_completed' when updating
v1.x metadata.
But this is wrong, and we will shortly make limited use of this
field in v0.90 metadata.
So move the update into common code.
Signed-off-by: NeilBrown <neilb@suse.de>
Rafael debugged a resume-time hang (with oopses in workqueue handling)
on his laptop that was due to the 'waker' workqueue entry being
disconnected and then released without the workqueue entry having been
synchronized.
Several people were involved, with Oleg Nesterov doing a debugging patch
showing what workqueue entry was corrupt etc.
This was a regression introduced by commit 7bee549e19 ("Bluetooth: Add
USB autosuspend support to btusb driver") as Rafael points out (not
actually bisected, but it became clear once the bug was found).
Tested-and-reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Oliver Neukum <oliver@neukum.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
x86/PCI: Adjust GFP mask handling for coherent allocations
PCI ASPM: fix oops on root port removal
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (52 commits)
drm/kms: Init the CRTC info fields for modes forced from the command line.
drm/radeon/r600: CS parser updates
drm/radeon/kms: add debugfs for power management for AtomBIOS devices
drm/radeon/kms: initial mode validation support
drm/radeon/kms/atom/dce3: call transmitter init on mode set
drm/radeon/kms: store detailed connector info
drm/radeon/kms/atom/dce3: fix up usPixelClock calculation for Transmitter tables
drm/radeon/kms/r600: fix rs880 support v2
drm/radeon/kms/r700: fix some typos in chip init
drm/radeon/kms: remove some misleading debugging output
drm/radeon/kms: stop putting VRAM at 0 in MC space on r600s.
drm/radeon/kms: disable D1VGA and D2VGA if enabled
drm/radeon/kms: Don't RMW CP_RB_CNTL
drm/radeon/kms: fix coherency issues on AGP cards.
drm/radeon/kms: fix rc410 suspend/resume.
drm/radeon/kms: add quirk for hp dc5750
drm/radeon/kms/atom: fix potential oops in spread spectrum code
drm/kms: typo fix
drm/radeon/kms/atom: Make card_info per device
drm/radeon/kms/atom: Fix DVO support
...
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (27 commits)
V4L/DVB (13314): saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150
V4L/DVB (13313): saa7134: add support for FORCE_TS_VALID mode for mpeg ts input
V4L/DVB (13311): uvcvideo: Fix compilation warning with 2.6.32 due to type mismatch with abs()
V4L/DVB (13309): uvcvideo: Ignore the FIX_BANDWIDTH for compressed video
V4L/DVB (13287): ce6230 - saa7164-cmd: Fix wrong sizeof
V4L/DVB (13286): pxa-camera: Fix missing sched.h
V4L/DVB (13264): gspca_mr97310a: Change vstart for CIF sensor type 1 cams
V4L/DVB (13257): gspca - m5602-s5k4aa: Add vflip for Fujitsu Amilo Xi 2528
V4L/DVB (13256): gspca - m5602-s5k4aa: Add another MSI GX700 vflip quirk
V4L/DVB (13255): gspca - m5602-s5k4aa: Add vflip quirk for the Bruneinit laptop
V4L/DVB (13240): firedtv: fix regression: tuning fails due to bogus error return
V4L/DVB (13237): firedtv: length field corrupt in ca2host if length>127
V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes
V4L/DVB (13202): smsusb: add autodetection support for three additional Hauppauge USB IDs
V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming
V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard
V4L/DVB (13169): bttv: Fix potential out-of-order field processing
V4L/DVB (13167): pt1: Fix a compile error on arm
V4L/DVB (13132): fix use-after-free Oops, resulting from a driver-core API change
V4L/DVB (13131): pxa_camera: fix camera pixel format configuration
...
A negative offset could be used to index before the event buffer and
lead to a security breach.
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Now that input core acquires dev->event_lock spinlock and disables
interrupts when propagating input events, using spin_lock_bh() in
ff-memless driver is not allowed. Actually, the timer_lock itself
is not needed anymore, we should simply use dev->event_lock
as well.
Also do a small cleanup in force-feedback core.
Reported-by: kerneloops.org
Reported-by: http://www.kerneloops.org/searchweek.php?search=ml_ff_set_gain
Reported-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Turn on RTS/CTS for HT to prevent uCode TX fifo underrun
This is fix for
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2103
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Jiajia Zheng <jiajia.zheng@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection
mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field
in the HT Information Element to determine whether or not to use
protection.
The Operating Mode field has 4 possible settings: 0-3:
Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the
BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT
stations in a 20 MHz BSS
Mode 1: used if there are non-HT stations or APs using the primary or
secondary channels
Mode 2: if only HT stations are associated in the BSS and at least one
20 MHz HT station is associated.
Mode 3: used if one or more non-HT stations are associated in the BSS.
When in operating modes 1 or 3, and the Use_Protection field is 1 in the
Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or
CTS-to-Self.
By default, CTS-to-self is the preferred protection mechanism for less
overhead and higher throughput; but using the full RTS/CTS will better
protect the inner exchange from interference, especially in
highly-congested environment.
For 6000 series WIFI NIC, RTS/CTS protection mechanism is the
recommended choice for HT traffic based on the HW design.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Configuration of wake-on-lan for unicast, multicast, broadcast, physical
activity was not working. Kernel panic issue was there when user tries to
disable WOL. Fixed them.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to a missing header include, sparse generates the following warnings:
CHECK drivers/net/wireless/rtl818x/rtl8187_rfkill.c
warning: symbol 'rtl8187_rfkill_init' was not declared. Should it be static?
warning: symbol 'rtl8187_rfkill_poll' was not declared. Should it be static?
warning: symbol 'rtl8187_rfkill_exit' was not declared. Should it be static?
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Setup the GPIOs for the BenQ Joybook netbook.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add GPIO configuration for the Compaq CQ60 laptop
Reported-by: David Dreggors <ddreggors@jumptv.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should not zero out the multicast hash when configuring
the operating mode, since a zero value means all multicast
frames will get dropped. Also, ath5k_mode_setup() gets
called after any reset, so the hash already set up in
configure_filter() is lost.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ops->set_tim() must be atomic, so b43 trying to acquire a mutex leads
to a kernel crash. This patch trades an easy to trigger crash in AP
mode for an unlikely race condition. According to Michael, the real
fix would be to allow set_tim() to sleep, since b43 is not the only
driver that needs to sleep in all callbacks.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The scan function was using 32 bit access which does not
work on 16bit CF cards.
This patch corrects this by doing two 16 bit reads like
ssb_pcmcia_read32 already does.
mb -- Removed locking. That early in init there's no need for locking.
Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit d79c326 ("gpio-addr-flash: new driver for GPIO assisted
flash addressing") removed two lines from the Makefile by accident.
Though I'm not sure how this accident happened, this patch reverts the
removal.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chris Wright has some patches which let us fall back to swiotlb nicely
if IOMMU initialisation fails. But those are a bit much for 2.6.32.
Instead, let's shift the check for the biggest problem, the HP and Acer
BIOS bug which reports a DMAR at physical address zero. That one can
actually be checked much earlier -- before we even admit to having
detected an IOMMU in the first place. So the swiotlb init goes ahead as
we want.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
i2c: Add an interface to lock/unlock an I2C bus segment
i2c-piix4: Modify code name SB900 to Hudson-2
* 'for-linus' of git://neil.brown.name/md:
md/raid5: make sure curr_sync_completes is uptodate when reshape starts
md: don't clear endpoint for resync when resync is interrupted.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (34 commits)
net/fsl_pq_mdio: add module license GPL
can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo()
can: should not use __dev_get_by_index() without locks
hisax: remove bad udelay call to fix build error on ARM
ipip: Fix handling of DF packets when pmtudisc is OFF
qlge: Set PCIe reset type for EEH to fundamental.
qlge: Fix early exit from mbox cmd complete wait.
ixgbe: fix traffic hangs on Tx with ioatdma loaded
ixgbe: Fix checking TFCS register for TXOFF status when DCB is enabled
ixgbe: Fix gso_max_size for 82599 when DCB is enabled
macsonic: fix crash on PowerBook 520
NET: cassini, fix lock imbalance
ems_usb: Fix byte order issues on big endian machines
be2net: Bug fix to send config commands to hardware after netdev_register
be2net: fix to set proper flow control on resume
netfilter: xt_connlimit: fix regression caused by zero family value
rt2x00: Don't queue ieee80211 work after USB removal
Revert "ipw2200: fix oops on missing firmware"
decnet: netdevice refcount leak
netfilter: nf_nat: fix NAT issue in 2.6.30.4+
...
* 'sh/for-2.6.32' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
sh: Replace old style lock initializer
sh: Account for cache aliases in flush_icache_range()
sh: unwinder: Fix up invalid PC refetch in dwarf unwinder.
serial: sh-sci: disable callback typo fix
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: sleep: another HP/Compaq DMI entries for init_set_sci_en_on_resume
ACPI: add DMI entry for SCI_EN resume quirk on HP dv4
thermal: sysfs-api.txt - document passive attribute for thermal zones
thermal: sysfs-api.txt - reformat for improved readability
acpi: thermal: Add EOL to the trip_point_N_type strings
ACPI: Move dereference after NULL test
ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."
ACPI: add __cpuinit to acpi_processor_add()
acpi-power-meter: Don't leak ACPI error codes to userspace
eeepc-laptop: don't enable camera at startup if it's already on.
Revert "eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated"
ACPI: clean up video.c boundary checks and types
or it will taint the kernel and fail to load becuase
of_address_to_resource() is GPL only.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
is thrown when the CAN device is registered due to insufficient
skb space, as reported by various users. This patch adds the
rtnl_link_ops "get_size" to fix the problem. I think this patch
is required for more recent kernels as well, even if no WARN_ON
dumps are triggered. Maybe we also need "get_xstats_size" for
the CAN xstats.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit
to be set in order to function properly. This change will work on the early
revisions on the board as well, but the final revision will not function
without this change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input
without requiring TS_VALID set high. This is required for some new boards
to function properly, due to the hardware design implementation.
The configuration is toggled within the board setup configuration. Boards
that do not have this bit set will function as before with no change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The abs() macro has changed in 2.6.32 and returns a long instead of an
int. Fix the driver to avoid compilation warnings.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The FIX_BANDWIDTH quirk tries to work around cameras requesting the
maximum bandwidth regardless of the image size by computing a bandwidth
estimate. This works only for uncompressed frames.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Cc: Antti Palosaari <crope@iki.fi>
Acked-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_mr97310a: Change vstart for CIF sensor type 1 cams
This fixes the distortion at the end of the frame, and avoids the bad frame
dropping done because of this distortion, trippling the framerate!
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds another vflip quirk for the MSI GX700.
Thanks to John Katzmaier for reporting.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since 2.6.32(-rc1), DVB core checks the return value of
dvb_frontend_ops.set_frontend. Now it becomes apparent that firedtv
always returned a bogus value from its set_frontend method.
CC: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This solves a problem in firedtv that has become major for Swedish DVB-T
users the last month or so. It will most likely solve issues seen by
other users as well.
If the length of an AVC message is greater than 127, the length field
should be encoded in LV mode instead of V mode. V mode can only be used
if the length is 127 or less. This patch ensures that the CA_PMT
message is always encoded in LV mode so PMT message of greater lengths
can be supported.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this "is anyone waiting on this?" check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: stable@kernel.org
Add support for three new Hauppauge Device USB IDs:
2040:b900
2040:b910
2040:c000
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Because the counters were not reset when starting up streaming, they would
be reused from the previous run. This can result in cases such that when the
second instance of streaming starts up, the "cnt" variable in
em28xx_audio_isocirq() can end up being negative, resulting in attempting to
write to memory before the start of runtime->dma_area (as well as having a
negative number of bytes to copy).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value. It is
"optional" based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard. The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.
This if-statement appears to have been written to assume wrong
memcmp() semantics. That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values. That doesn't make any sense. One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.
The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC. If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame. In the case I was
testing this actually caused black video frames to be displayed.
Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison. It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen. One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.
The solution is to fix the sense of the if-statement. It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single "!" character from the
if-statement in set_tvnorm in bttv-driver.c.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a subtle interaction in the bttv driver which can result in
fields being repeatedly processed out of order. This is a problem
specifically when running in V4L2_FIELD_ALTERNATE mode (probably the
most common case).
1. The determination of which fields are associated with which buffers
happens in videobuf, before the bttv driver gets a chance to queue the
corresponding DMA. Thus by the point when the DMA is queued for a
given buffer, the algorithm has to do the queuing based on the
buffer's already assigned field type - not based on which field is
"next" in the video stream.
2. The driver normally tries to queue both the top and bottom fields
at the same time (see bttv_irq_next_video()). It tries to sort out
top vs bottom by looking at the field type for the next 2 available
buffers and assigning them appropriately.
3. However the bttv driver *always* actually processes the top field
first. There's even an interrupt set aside for specifically
recognizing when the top field has been processed so that it can be
marked done even while the bottom field is still being DMAed.
Given all of the above, if one gets into a situation where
bttv_irq_next_video() gets entered when the first available buffer has
been pre-associated as a bottom field, then the function is going to
process the buffers out of order. That first available buffer will be
put into the bottom field slot and the buffer after that will be put
into the top field slot. Problem is, since the top field is always
processed first by the driver, then that second buffer (the one after
the first available buffer) will be the first one to be finished.
Because of the strict fifo handling of all video buffers, then that
top field won't be seen by the app until after the bottom field is
also processed. Worse still, the app will get back the
chronologically later bottom field first, *before* the top field is
received. The buffer's timestamps will even be backwards.
While not fatal to most TV apps, this behavior can subtlely degrade
userspace deinterlacing (probably will cause jitter). That's probably
why it has gone unnoticed. But it will also cause serious problems if
the app in question discards all but the latest received buffer (a
latency minimizing tactic) - causing one field to only ever be
displayed since the other is now always late. Unfortunately once you
get into this state, you're stuck this way - because having consumed
two buffers, now the next time around the "first" available buffer
will again be a bottom field and the same thing happens.
How can we get into this state? In a perfect world, where there's
always a few free buffers queued to the driver, it should be
impossible. However if something disrupts streaming, e.g. if the
userspace app can't queue free buffers fast enough for a moment due
perhaps to a CPU scheduling glitch, then the driver can get
momentarily starved and some number of fields will be dropped. That's
OK. But if an odd number of fields get dropped, then that "first"
available buffer might be the bottom field and now we're stuck...
This patch fixes that problem by deliberately only setting up a single
field for one frame if we don't get a top field as the first available
buffer. By purposely skipping the other field, then we only handle a
single buffer thus bringing things back into proper sync (i.e. top
field first) for the next frame. To do this we just drop the few
lines in bttv_irq_next_video() that attempt to set up the second
buffer when that second buffer isn't for the bottom field.
This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In
the other modes this change either has no effect or doesn't harm
things any further anyway.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The lack of #include <linux/vmalloc.h> caused a compile error on some
architectures.
Signed-off-by: HIRANO Takahito <hiranotaka@zng.info>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit b402843787 has broken again re-use of
device objects across device_register() / device_unregister() cycles. Fix
soc-camera by nullifying the struct after device_unregister().
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
