Early chipsets (gen2/3) used function 1 as a placeholder for multi-head.
We used to ignore these since they were not assigned to
PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all
Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu
systems. This fails hard on gen2/3.
Reported-by: Ferenc Wágner <wferi@niif.hu>
Tested-by: Ferenc Wágner <wferi@niif.hu>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
This error is reported by cppcheck:
drivers/net/vxge/vxge-config.c:3693: warning: Mutual exclusion over || always evaluates to true. Did you intend to use && instead?
It looks like cppcheck is correct, so fix this. No test was run.
Cc: Ramkrishna Vepa <ramkrishna.vepa@exar.com>
Cc: Sivakumar Subramani <sivakumar.subramani@exar.com>
Cc: Sreenivasa Honnur <sreenivasa.honnur@exar.com>
Cc: Jon Mason <jon.mason@exar.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Acked-by: Ram Vepa <ram.vepa@exar.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
free the skb's when the Tx of PAPRD frames fails and also add a debug
message indicating that.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For the following rule:
iptables -I PREROUTING -t raw -j CT --ctevents assured
The event delivered looks like the following:
[UPDATE] tcp 6 src=192.168.0.2 dst=192.168.1.2 sport=37041 dport=80 src=192.168.1.2 dst=192.168.1.100 sport=80 dport=37041 [ASSURED]
Note that the TCP protocol state is not included. For that reason
the CT event filtering is not very useful for conntrackd.
To resolve this issue, instead of conditionally setting the CT events
bits based on the ctmask, we always set them and perform the filtering
in the late stage, just before the delivery.
Thus, the event delivered looks like the following:
[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.2 dst=192.168.1.2 sport=37041 dport=80 src=192.168.1.2 dst=192.168.1.100 sport=80 dport=37041 [ASSURED]
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
In 135367b "netfilter: xtables: change xt_target.checkentry return type",
the type returned by checkentry was changed from boolean to int, but the
return values where not adjusted.
arptables: Input/output error
This broke arptables with the mangle target since it returns true
under success, which is interpreted by xtables as >0, thus
returning EIO.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
When built with rcu checks enabled, vhost triggers
bogus warnings as vhost features are read without
dev->mutex sometimes, and private pointer is read
with our kind of rcu where work serves as a
read side critical section.
Fixing it properly is not trivial.
Disable the warnings by stubbing out the checks for now.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The CX20442 codec driver never provided the snd_soc_codec_driver's
.reg_cache_default member. With the latest ASoC framework changes, it
seems to be referred unconditionally, resulting in a NULL pointer
dereference if missing. Provide it.
Created and tested on Amstrad Delta against linux-2.6.38-rc2
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The Amstrad Delta ASoC driver used to override the digital_mute()
callback, expected to be not provided by the on-board CX20442 CODEC
driver, with its own implementation. While this is still posssible when
substituting the whole empty snd_soc_dai_driver.ops member (the CX20442
case), replacing snd_soc_dai_ops.digital_mute only is no longer correct
after the snd_soc_dai_driver.ops member has been constified, and results
in build error.
Drop this actually not used code path in hope the CX20442 driver never
provides its own snd_soc_dai_ops structure.
Created and tested against linux-2.6.38-rc2
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Version 15 of schedstats was introduced in:
67aa0f767af4: sched: remove unused fields from struct rq
and removed three unused counters in sched_yield(). Update
the documentation.
Signed-off-by: Javi Merino <cibervicho@gmail.com>
Cc: henrix@sapo.pt
Cc: rdunlap@xenotime.net
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1296515496-8229-1-git-send-email-cibervicho@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This error was reported by cppcheck:
drivers/net/enc28j60.c:815: error: Using sizeof for array given as function argument returns the size of pointer.
The original code reads 4 or 8 bytes instead of TSV_SIZE (= 100) bytes.
I just fixed the code, but did not run any tests.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
In my testing of 2.6.37 I was occassionally getting a warning about
sysctl table entries being unregistered in the wrong order. Digging
in it turns out this dates back to the last great sysctl reorg done
where Al Viro introduced the requirement that sysctl directories
needed to be created before and destroyed after the files in them.
It turns out that in that great reorg /proc/sys/net/ipv6/neigh was
overlooked. So this patch fixes that oversight and makes an annoying
warning message go away.
>------------[ cut here ]------------
>WARNING: at kernel/sysctl.c:1992 unregister_sysctl_table+0x134/0x164()
>Pid: 23951, comm: kworker/u:3 Not tainted 2.6.37-350888.2010AroraKernelBeta.fc14.x86_64 #1
>Call Trace:
> [<ffffffff8103e034>] warn_slowpath_common+0x80/0x98
> [<ffffffff8103e061>] warn_slowpath_null+0x15/0x17
> [<ffffffff810452f8>] unregister_sysctl_table+0x134/0x164
> [<ffffffff810e7834>] ? kfree+0xc4/0xd1
> [<ffffffff813439b2>] neigh_sysctl_unregister+0x22/0x3a
> [<ffffffffa02cd14e>] addrconf_ifdown+0x33f/0x37b [ipv6]
> [<ffffffff81331ec2>] ? skb_dequeue+0x5f/0x6b
> [<ffffffffa02ce4a5>] addrconf_notify+0x69b/0x75c [ipv6]
> [<ffffffffa02eb953>] ? ip6mr_device_event+0x98/0xa9 [ipv6]
> [<ffffffff813d2413>] notifier_call_chain+0x32/0x5e
> [<ffffffff8105bdea>] raw_notifier_call_chain+0xf/0x11
> [<ffffffff8133cdac>] call_netdevice_notifiers+0x45/0x4a
> [<ffffffff8133d2b0>] rollback_registered_many+0x118/0x201
> [<ffffffff8133d3af>] unregister_netdevice_many+0x16/0x6d
> [<ffffffff8133d571>] default_device_exit_batch+0xa4/0xb8
> [<ffffffff81337c42>] ? cleanup_net+0x0/0x194
> [<ffffffff81337a2a>] ops_exit_list+0x4e/0x56
> [<ffffffff81337d36>] cleanup_net+0xf4/0x194
> [<ffffffff81053318>] process_one_work+0x187/0x280
> [<ffffffff8105441b>] worker_thread+0xff/0x19f
> [<ffffffff8105431c>] ? worker_thread+0x0/0x19f
> [<ffffffff8105776d>] kthread+0x7d/0x85
> [<ffffffff81003824>] kernel_thread_helper+0x4/0x10
> [<ffffffff810576f0>] ? kthread+0x0/0x85
> [<ffffffff81003820>] ? kernel_thread_helper+0x0/0x10
>---[ end trace 8a7e9310b35e9486 ]---
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
axnet_cs:
mdelay of 10ms is too long at ei_rx_overrun.
It should be reduced to 2ms.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
In get_rps_cpu, add check that the rps_flow_table for the device is
NULL when trying to take fast path when RPS map length is one.
Without this, RFS is effectively disabled if map length is one which
is not correct.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The cERROR message in checkSMB when the calculated length doesn't match
the RFC1001 length is incorrect in many cases. It always says that the
RFC1001 length is bigger than the SMB, even when it's actually the
reverse.
Fix the error message to say the reverse of what it does now when the
SMB length goes beyond the end of the received data. Also, clarify the
error message when the RFC length is too big. Finally, clarify the
comments to show that the 512 byte limit on extra data at the end of
the packet is arbitrary.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
arch/arm/mach-omap2/dma.c: Convert IS_ERR result to PTR_ERR
arm: omap2: mux: fix compile warning
omap1: Simplify use of omap_irq_flags
omap2+: Fix unused variable warning for omap_irq_base
Fix kernel-doc warning in kernel.h from commit 7ef88ad561
("BUILD_BUG_ON: make it handle more cases"):
Warning(include/linux/kernel.h:605): No description found for parameter 'condition'
Warning(include/linux/kernel.h:605): Excess function parameter 'cond' description in 'BUILD_BUG_ON'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patches should keep coming through Rusty but it helps if I'm Cc'd as
well.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (42 commits)
usb: gadget: composite: avoid access beyond array max length
USB: serial: handle Data Carrier Detect changes
USB: gadget: Fix endpoint representation in ci13xxx_udc
USB: gadget: Fix error path in ci13xxx_udc gadget probe function
usb: pch_udc: Fix the worning log issue at gadget driver remove
USB: serial: Updated support for ICOM devices
USB: ehci-mxc: add work-around for efika mx/sb bug
USB: unbreak ehci-mxc on otg port of i.MX27
drivers: update to pl2303 usb-serial to support Motorola cables
USB: adding USB support for Cinterion's HC2x, EU3 and PH8 products
USB serial: add missing .usb_driver field in serial drivers
USB: ehci-fsl: Fix 'have_sysif_regs' detection
USB: g_printer: fix bug in module parameter definitions
USB: g_printer: fix bug in unregistration
USB: uss720: remove duplicate USB device
MAINTAINERS: add ueagle-atm entry
USB: EHCI: fix DMA deallocation bug
USB: pch_udc: support new device ML7213 IOH
usb: pch_udc: Fixed issue which does not work with g_serial
usb: set ep_dev async suspend should be later than device_initialize
...
* 'staging-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (26 commits)
staging: r8712u: Add new device IDs
staging: brcm80211: fix suspend/resume issue in brcmsmac
staging: brcm80211: remove assert to avoid panic since 2.6.37 kernel
Staging: iio: Aditional fixpoint formatted output bugfix
staging: usbip: vhci: use urb->dev->portnum to find port
staging: usbip: vhci: handle EAGAIN from SO_RCVTIMEO
staging: usbip: vhci: friendly log messages for connection errors
staging: usbip: vhci: refuse to enqueue for dead connections
staging: usbip: vhci: give back URBs from in-flight unlink requests
staging: usbip: vhci: update reference count for usb_device
staging: usbip: stub: update refcounts for devices and interfaces
staging: tidspbridge: replace mbox callback with notifier_call
staging: comedi: ni_labpc: Use shared IRQ for PCMCIA card
Staging: speakup: &&/|| confusion in silent_store()
iio: Fixpoint formatted output bugfix
staging: rt2860: Fix incorrect netif_stop_queue usage warning
staging: r8712u: Fix memory leak in firmware loading
staging: tidspbridge: configure full L1 MMU range
staging: rt2870sta: Add ID for Linksys WUSB100v2
Staging: xgfib: put parenthesis in the right place
...
* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
tty/serial: fix apbuart build
n_hdlc: fix read and write locking
serial: unbreak billionton CF card
tty: use for_each_console() and WARN() on sysfs failures
vt: fix issue when fbcon wants to takeover a second time.
Fix up trivial conflict in drivers/tty/tty_io.c
Allow non-ARM SMP processors to use the SMP_ON_UP feature. CPUs
supporting SMP must have the new CPU ID format, so check for this first.
Then check for ARM11MPCore, which fails the MPIDR check. Lastly check
the MPIDR reports multiprocessing extensions and that the CPU is part of
a multiprocessing system.
Cc: <stable@kernel.org>
Reported-and-Tested-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Without this dependency the softing driver will be buildable on s390,
where it fails.
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an IPSEC SA is still being set up, __xfrm_lookup() will return
-EREMOTE and so ip_route_output_flow() will return a blackhole route.
This can happen in a sndmsg call, and after d33e455337 ("net: Abstract
default MTU metric calculation behind an accessor.") this leads to a
crash in ip_append_data() because the blackhole dst_ops have no
default_mtu() method and so dst_mtu() calls a NULL pointer.
Fix this by adding default_mtu() methods (that simply return 0, matching
the old behavior) to the blackhole dst_ops.
The IPv4 part of this patch fixes a crash that I saw when using an IPSEC
VPN; the IPv6 part is untested because I don't have an IPv6 VPN, but it
looks to be needed as well.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When DEBUG_SPI is included in the debug log level wl1271_spi_reset()
will dump the already freed memory instead of the SPI buffer.
This bug was spotted by the semantic patch tool coccinelle using the
script found at scripts/coccinelle/free/kfree.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Missed one change as per earlier suggestion.
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
One saa7111 device is reporting a different ID:
saa7115 0-0024: chip found @ 0x48 (ID 0f7111d0e111111) does not match a known saa711x chip.
As this is for sure a saa7111, change the detection code to also
cover this device.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
New compiler warnings that I noticed when building a patchset based
on recent Fedora kernel:
fs/cifs/cifssmb.c: In function 'CIFSSMBSetFileSize':
fs/cifs/cifssmb.c:4813:8: warning: variable 'data_offset' set but not used
[-Wunused-but-set-variable]
fs/cifs/file.c: In function 'cifs_open':
fs/cifs/file.c:349:24: warning: variable 'pCifsInode' set but not used
[-Wunused-but-set-variable]
fs/cifs/file.c: In function 'cifs_partialpagewrite':
fs/cifs/file.c:1149:23: warning: variable 'cifs_sb' set but not used
[-Wunused-but-set-variable]
fs/cifs/file.c: In function 'cifs_iovec_write':
fs/cifs/file.c:1740:9: warning: passing argument 6 of 'CIFSSMBWrite2' from
incompatible pointer type [enabled by default]
fs/cifs/cifsproto.h:337:12: note: expected 'unsigned int *' but argument is
of type 'size_t *'
fs/cifs/readdir.c: In function 'cifs_readdir':
fs/cifs/readdir.c:767:23: warning: variable 'cifs_sb' set but not used
[-Wunused-but-set-variable]
fs/cifs/cifs_dfs_ref.c: In function 'cifs_dfs_d_automount':
fs/cifs/cifs_dfs_ref.c:342:2: warning: 'rc' may be used uninitialized in
this function [-Wuninitialized]
fs/cifs/cifs_dfs_ref.c:278:6: note: 'rc' was declared here
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Recently CIFS was changed to use the kernel crypto API for MD4 hashes,
but the Kconfig dependencies were not changed to reflect this.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reported-and-Tested-by: Suresh Jayaraman <sjayaraman@suse.de>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
The streamzap driver has relatively low sampling resolution, and any
delays in reporting events seem to cause some minor problems for the
likes of irw when using the lirc bridge driver, resulting in a single
keypress registering as multiple independent ones, rather than as a
single press with repeats. If we call ir_raw_event_handle() more
frequently and reset the rawir kfifo at end-of-signal, the behavior
improves quite a bit.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make sure rawir struct is zeroed out before populating it for each
ir_raw_event_store_with_filter() call, and when we see a trailing 0x80
packet (end-of-data), issue an ir_raw_event_reset() call.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to my own stupidity, some of the wrong time unit conversion macros
were being used inside some of the IR drivers I've been working on. Fix
that, and convert over some additional places to also use the macros.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some occasionally useful debug spew disappeared as part of a feature
update a while back, and I'm finding myself in need of it again to help
diagnose some issues.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the same "are you ready?" i2c_master_send() poll command to
get_key_haup_xvr found in lirc_zilog, which is apparently seen in
the Windows driver for the PVR-150 w/a z8. This stabilizes what is
received from both the HD-PVR and HVR-1950, even with their polling
intervals at the default of 100, thus the removal of the custom
260ms polling_interval in pvrusb2-i2c-core.c.
Acked-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Mike Isely <isely@isely.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both the HD-PVR and HVR-1950, driven by the hdpvr and pvrusb2 drivers
respectively, have a zilog z8 chip exposed via i2c. These are both
usb-connected devices, and on both of them, back-to-back i2c_master_send
calls that work fine with a z8 on a pci card fail with a -EIO, as the
chip isn't yet ready from the prior command. To cope with that, add a
delay and retry loop where necessary.
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We have to actually call i2c_new_device() once for each of the rx and tx
addresses. Also improve error-handling and device remove i2c cleanup.
Reviewed-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Per http://mediacenterguides.com/book/export/html/31 and investigation
by Erin, we were missing these last three mappings to complete the mce
key table. Lets remedy that.
Reported-by: Erin Simonds <fisslefink@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In some cases, some frames may not end with the JPEG end of frame.
Being not complete, they are now discarded.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The problem was introduced by the commit 2af0b4c60c.
Some registers were no more initialized.
Tested-by: <Giovanni Scafora giovanni@archlinux.org>
Tested-by: <Sergey Manucharian sm@ingeniware.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hugh Dickins found that characters in xterm were going missing and oft
delayed. Being the curious type, he managed to associate this with the
new high-precision vblank patches; disabling these he found, restored
the orderliness of his characters.
The oddness begins when one realised that Hugh was not using vblanks at
all on his system (fvwm and some xterms). Instead, all he had to go on
were warning of a pipe underrun, curiously enough at around 60Hz. He
poked and found that in addition to the underrun warning, the hardware
was flagging the start of a new frame, a vblank, which in turn was
kicking off the pending vblank processing code.
There is little we can do for the underruns on Hugh's machine, a
Crestline [965GM], which must have its FIFO watermarks set to 8.
However, we do not need to process the vblank if we know that they are
disabled...
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By setting the FB of a CRTC to NULL, we are turning off the CRTC (and so
disable the unused encoders and connectors). As such we can simplify the
later tests by making sure the set->mode is NULL. Setting the
num_connectors to zero means that we do not need to loop over the unused
connectors.
All current usage appears correct, this only builds additional defense
into the routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=27722
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson