vfree() does its own 'NULL' check, so no need for check before
calling it.
Signed-off-by: Figo.zhang <figo1802@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If mlx4_create_eq() would fail for one of EQ's assigned for
completion handling, the code would try to free the same EQ
we failed to create.
The crash was found by Christoph Lameter
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the right structure while incrementing the offset in tun_get_user.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Increment the iovec base by the offset passed in for the initial
copy_to_user() in memcpy_to_iovecend().
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
skb_dma_unmap() is quite expensive for small packets,
because we use two different cache lines from skb_shared_info.
One to access nr_frags, one to access dma_maps[0]
Instead of dma_maps being an array of MAX_SKB_FRAGS + 1 elements,
let dma_head alone in a new dma_head field, close to nr_frags,
to reduce cache lines misses.
Tested on my dev machine (bnx2 & tg3 adapters), nice speedup !
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Get rid of num_dma_maps in struct skb_shared_info, as it seems unused.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove the private definition of TRUE/FALSE and use the ones from
linux/stddef.h. Also remove the definition of BOOL which is not referenced
inside the driver anyway.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a driver for the Micrel KS8842 ethernet switch.
The supplied code is for driving the KS8842 through the Timberdale FPGA
on the Russellville board, a development board for Intel Atom CPU
in the automotive area.
Signed-off-by: Richard Röjfors <richard.rojfors.ext@mocean-labs.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On Thu, Jun 04, 2009 at 09:06:00PM +1000, Herbert Xu wrote:
>
> tun: Optimise handling of bogus gso->hdr_len
>
> As all current versions of virtio_net generate a value for the
> header length that's too small, we should optimise this so that
> we don't copy it twice. This can be done by ensuring that it is
> at least as large as the place where we'll write the checksum.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
With this applied we can strengthen the partial checksum check:
In skb_partial_csum_set we check to see if the checksum offset
is within the packet. However, we really should check that it
is within the skb head as that's the only bit we can modify
without copying.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
As all current versions of virtio_net generate a value for the
header length that's too small, we should optimise this so that
we don't copy it twice. This can be done by ensuring that it is
at least as large as the place where we'll write the checksum.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Through a bug in the tun driver, I noticed that virtio_net is
producing bogus hdr_len values. In particular, it only includes
the IP header in the linear area, and excludes the entire TCP
header. This causes the TCP header to be copied twice for each
packet. (The bug omitted the second copy :)
This patch corrects this.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes an initialization error; the chip negotiates gigabit, but
the driver mistakenly handled it as 100Mb.
Changes based on both SiS own GPL driver and forcedeth.
Hopefully should fix
http://bugzilla.kernel.org/show_bug.cgi?id=9735http://bugzilla.kernel.org/show_bug.cgi?id=11149
Signed-off-by: Riccardo Ghetta <birrachiara@tin.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Corrected dma sync handling on small packets. Should fix
http://bugzilla.kernel.org/show_bug.cgi?id=11509
Note:
While this bug was reported only on x86_64, it could have affected
any architecture.
Signed-off-by: Riccardo Ghetta <birrachiara@tin.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some firmware mailbox commands require the firmware to
communicate with the FCoE driver running on another
PCI function. This can potentially take several seconds.
This wait is done in process context only.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are 8 banks of 'sub-registers' each of which are accessed
through address/data register pair. An example would be reading
flash or the xgmac. Accessing these require the driver to wait for
a ready bit before writing the address and then accessing the data.
This patch increases the timeout to 100us to prevent timeouts
that have been seen on some platforms.
These register are accessed in process context only.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since an FCoE function shares a port with this NIC function, the
jumbo settings must always be in place. This patch causes the
hardware to be set up for jumbo if it is not already done.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Each firmware mailbox command can have a different number of
valid data elements. When waiting for a mailbox command to
complete it the process passes it's element count and
waits for the completion. It is possible that while waiting
an unrelated firmware async event (AE) can arrive. When this
happens, the handler will over write the element count
with the value for the newly arrived AE. This can cause
the mailbox command to not get all of it's data.
This patch restores original mailbox count at the end
of the handler.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Check status on every iteration of event handler loop and exit
if an error occurred. If an error occurred then recover process
will be queued so this loop should no continue.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The smsc911x_drv_remove() function is declared with __devexit, so the
assignment to the driver structure needs __devexit_p() wrappings to prevent
build failure when hotplug is disabled.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The smsc911x driver works fine on Blackfin systems, so add it to the arch
list in the Kconfig.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before:
$ perf report
failed to open file: No such file or directory
After:
$ perf report
failed to open file: perf.data (try 'perf record' first)
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
If perf is run on a !CONFIG_PERF_COUNTER kernel right now it
bails out with no messages or with confusing messages.
Standardize this case some more and explain the situation.
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On architectures/CPUs without PMU support but with perfcounters
enabled 'perf record' currently fails because it cannot create a
cycle based hw-perfcounter.
Fall back to the cpu-clock-tick sw-perfcounter in this case, which
is hrtimer based and will always work (as long as perfcounters
are enabled).
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On architectures/CPUs without PMU support but with perfcounters
enabled 'perf top' currently fails because it cannot create a
cycle based hw-perfcounter.
Fall back to the cpu-clock-tick sw-perfcounter in this case, which
is hrtimer based and will always work (as long as perfcounters
is enabled).
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This header is sometimes included in the uncompress stage to get
register values, but no <linux/amba/bus.h> can be included there.
So declare "struct amba_device" here before using it in a prototype.
Signed-off-by: Alessandro Rubini <rubini@unipv.it>
Acked-by: Andrea Gallo <andrea.gallo@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Before:
$ perf stat ~/hackbench 5
error: syscall returned with -1 (No such device)
After:
$ perf stat ~/hackbench 5
Time: 1.640
Performance counter stats for '/home/mingo/hackbench 5':
6524.570382 task-clock-ticks # 3.838 CPU utilization factor
35704 context-switches # 0.005 M/sec
191 CPU-migrations # 0.000 M/sec
8958 page-faults # 0.001 M/sec
<not counted> cycles
<not counted> instructions
<not counted> cache-references
<not counted> cache-misses
Wall-clock time elapsed: 1699.999995 msecs
Also add -v (--verbose) option to allow the printing of failed
counter opens.
Plus dont print 'inf' if wall-time is zero (due to jiffies granularity),
instead skip the printing of the CPU utilization factor.
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
vfree() does its own 'NULL' check, so no need for check before
calling it.
In v2, remove the stray newline.
[ Impact: cleanup ]
Signed-off-by: Figo.zhang <figo1802@gmail.com>
Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
LKML-Reference: <1244385036.3402.11.camel@myhost>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This fixes a stack corruption panic or null dereference oops
due to a bad GS in resume_userspace() when returning from
sys_vm86() and calling lockdep_sys_exit().
Only a problem when CONFIG_LOCKDEP and CONFIG_CC_STACKPROTECTOR
enabled.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Cc: H. Peter Anvin <hpa@zytor.com>
LKML-Reference: <1244384628.2323.4.camel@bimbo>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Ingo Molnar reported that read_apic is buggy novadays:
[ 0.000000] Using APIC driver default
[ 0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[ 0.000000] APIC: disable apic facility
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at arch/x86/kernel/apic/apic.c:254 native_apic_read_dummy+0x2d/0x3b()
[ 0.000000] Hardware name: HP OmniBook PC
Indeed we still rely on apic->read operation for SMP compiled
kernel. And instead of disfigure the SMP code with #ifdef we
allow to call apic->read. To capture any unexpected results
we check for apic->read being called for sane reason via
WARN_ON_ONCE but(!) instead of OR we should use AND logical
operation (thanks Yinghai for spotting the root of the problem).
Along with that we could be have bad MP table and we are
to fix it that way no SMP started and no complains about
BIOS bug if apic was just disabled via command line.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090607124840.GD4547@lenovo>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The Dell Optiplex 360 hangs on reboot, just like the Optiplex 330, so
the same quirk is needed.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Steve Conklin <steve.conklin@canonical.com>
Cc: Leann Ogasawara <leann.ogasawara@canonical.com>
Cc: <stable@kernel.org>
LKML-Reference: <200906051202.38311.jdelvare@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Add IDE_DFLAG_NIEN_QUIRK device flag and use it instead of
drive->quirk_list.
There should be no functional changes caused by this patch.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add ide_check_nien_quirk_list() helper to the core code
and then use it in ide_port_tune_devices().
* Remove no longer needed ->quirkproc methods from hpt366.c
and pdc202xx_{new,old}.c.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Enable also quirks in do_reset1() and ide_config_drive_speed()
for devices on quirk_drives[] list.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
With ->write_devctl method call (which unmasks drive IRQ) preceding
SELECT_MASK() call there is really no need for the latter.
Moreover with the combination of HPT36x controller and the drive on
the quirk_drives[] list this can result in superfluous enable_irq()
call which in turn will trigger WARN() in __enable_irq().
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
We always call SELECT_MASK(drive, 0) after ide_dev_read_id() call
so there is no need to do it again in the error path.
Moreover with the combination of HPT36x controller and the drive on
the quirk_drives[] list this can result in superfluous enable_irq()
call which in turn will trigger WARN() in __enable_irq().
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
[inspired by pata_icside]
Enabling/disabling of card IRQs is handled fine by IRQ and IDE
subsystems so there is no need for custom ->maskproc method.
Moreover icside_maskproc() would enable IRQ only if it was already
enabled [because of 'if (state->enabled && !mask)' check].
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
These flags used to be bit numbers and now are single bits in the
->atapi_flags vector. Use them properly.
Spotted-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There are two sites where the flag is being changed: ide_retry_pc
and idetape_do_request. Both codepaths are protected by hwif->busy
(ide_lock_port) and therefore we shouldn't need the atomic accesses.
Spotted-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver's resetproc() method resets both channels at once -- most probably
by driving RESET- on them. Not only such reset can severely disturb concurrent
operations on another channel, it also ensues 2-second delay, while there's no
apparent reason why SRST reset being performed prior to resetproc() call needs
to be followed up by another reset.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver's dma_lost_irq() and dma_clear() methods call pdc202xx_reset()
which resets both channels at once -- most probably by driving RESET- on them.
Not only such reset can severely disturb concurrent operations on another
channel, it is also a clear overkill (especially in the first case) and is
completely unexpected and thus not properly handled by the IDE core in this
context (in the second case the usual SRST reset would most probably ensue
anyway though); it also causes quite arbitrary 2-second delay. Hence, use the
standard ide_dma_lost_irq() method and don't install the optional dma_clear()
method at all -- the driver should do well without this age-old cruft...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver's dma_test_irq() method, although tests some chip specific interrupt
bits, finally always relies on the SFF-8038i standard interrupt bit. I see no
point in testing the bits that are not trusted anyway -- the driver should be
fully able to use the standard method implemetation, ide_dma_test_irq().
With this change 'pdc202xx_dma_ops' finally becomes identical to 'sff_dma_ops',
and we can get rid of it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
With all the last patchsets going in for 82599 feature enablement, the
driver version needs to be increased for better identification.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
