When KVM is loaded, and hence VT set up, the vmcall instruction in an
lguest guest causes a #GP, not #UD.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (21 commits)
r8169: avoid losing MSI interrupts
tcp: tcp_vegas ssthresh bugfix
mac8390: fix regression caused during net_device_ops conversion
gianfar: fix BUG under load after introduction of skb recycling
wimax/i2400m: usb: fix device reset on autosuspend while not yet idle
RxRPC: Error handling for rxrpc_alloc_connection()
ipv4: Fix oops with FIB_TRIE
pktgen: do not access flows[] beyond its length
gigaset: beyond ARRAY_SIZE of iwb->data
IPv6: set RTPROT_KERNEL to initial route
net: fix rtable leak in net/ipv4/route.c
net: fix length computation in rt_check_expire()
wireless: beyond ARRAY_SIZE of intf->crypto_stats
iwlwifi: update 5000 ucode support to version 2 of API
cfg80211: fix race between core hint and driver's custom apply
airo: fix airo_get_encode{,ext} buffer overflow like I mean it...
ath5k: fix interpolation with equal power levels
iwlwifi: do not cancel delayed work inside spin_lock_irqsave
ath5k: fix exp off-by-one when computing OFDM delta slope
wext: verify buffer size for SIOCSIWENCODEEXT
...
If the asynchronous lease renewal fails (usually due to a soft timeout),
then we _must_ schedule state recovery in order to ensure that we don't
lose the lease unnecessarily or, if the lease is already lost, that we
recover the locking state promptly...
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fix build error with latest kbuild adjustments to initconst.
The commit a447c09324 ("vfs: Use
const for kernel parser table") changed:
static match_table_t __initdata tokens = {
to
static match_table_t __initconst tokens = {
But the missing const causes popwerpc to fail with latest
updates to __initconst like this:
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
The bug is only present with kbuild-next.
Following patch has been build tested.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
mlx4/connectX FRMR requires local write enable together with remote
rdma write enable. This fixes NFS/RDMA operation over the ConnectX
Infiniband HCA in the default memreg mode.
Signed-off-by: Vu Pham <vu@mellanox.com>
Signed-off-by: Tom Talpey <tmtalpey@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Two approaches for VGA detections: hot plug detection for 945G onwards
and load pipe detection for Pre-945G. Load pipe detection will get one free
pipe, set border color as red and blue, then check CRT status by
swf register. This is a sync-up with the 2D driver.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Slightly modified by trenn@suse.de -> only do this on fam 10h and fam 11h.
Currently powernow-k8 determines CPU frequency from ACPI PSS objects, but
according to AMD family 11h BKDG this frequency is just a rounded value:
"CoreFreq (MHz) = The CPU COF specified by MSRC001_00[6B:64][CpuFid]
rounded to the nearest 100 Mhz."
As a consequnce powernow-k8 reports wrong CPU frequency on some systems,
e.g. on Turion X2 Ultra:
powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82
processors (2 cpu cores) (version 2.20.00)
powernow-k8: 0 : pstate 0 (2200 MHz)
powernow-k8: 1 : pstate 1 (1100 MHz)
powernow-k8: 2 : pstate 2 (600 MHz)
But this is wrong as frequency for Pstate2 is 550 MHz. x86info reports it
correctly:
#x86info -a |grep Pstate
...
Pstate-0: fid=e, did=0, vid=24 (2200MHz)
Pstate-1: fid=e, did=1, vid=30 (1100MHz)
Pstate-2: fid=e, did=2, vid=3c (550MHz) (current)
Solution is to determine the frequency directly from Pstate MSRs instead
of using rounded values from ACPI table.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
- Make the message shorter and easier to grep for
- Use printk_once instead of WARN_ONCE (functionality of these was mixed)
Signed-off-by: Thomas Renninger <trenn@suse.de>
Cc: Langsdorf, Mark <mark.langsdorf@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(updated changelog)
cpufreq fix timer teardown in ondemand governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
>
(re-send with updated changelog)
cpufreq fix timer teardown in conservative governor
The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
workqueue handler to exit.
The ondemand governor does not seem to be affected because the
"if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
immediately without rescheduling the work. The conservative governor in
2.6.30-rc has the same check as the ondemand governor, which makes things
usually run smoothly. However, if the governor is quickly stopped and then
started, this could lead to the following race :
dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
This is why a synchronized teardown is required.
Depends on patch
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
The following patch applies to 2.6.30-rc2. Stable kernels have a similar
issue which should also be fixed, but the code changed between 2.6.29
and 2.6.30, so this patch only applies to 2.6.30-rc.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: gregkh@suse.de
CC: stable@kernel.org
CC: cpufreq@vger.kernel.org
CC: Ingo Molnar <mingo@elte.hu>
CC: rjw@sisk.pl
CC: Ben Slusky <sluskyb@paranoiacs.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
> Subject : cpufreq timer teardown problem
> Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date : 2009-04-23 14:00 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
> Handled-By : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Patch : http://patchwork.kernel.org/patch/19754/
> http://patchwork.kernel.org/patch/19753/
The patches linked above depend on the following patch to remove
circular locking dependency :
cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
(the following issue was faced when using cancel_delayed_work_sync() in the
timer teardown (which fixes a race).
* KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
> Hi
>
> my box output following warnings.
> it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
>
> A: work -> do_dbs_timer() -> cpu_policy_rwsem
> B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
>
>
Hrm, I think it must be due to my attempt to fix the timer teardown race
in ondemand governor mixed with new locking behavior in 2.6.30-rc.
The rwlock seems to be taken around the whole call to
cpufreq_governor_dbs(), when it should be only taken around accesses to
the locked data, and especially *not* around the call to
dbs_timer_exit().
Reverting my fix attempt would put the teardown race back in place
(replacing the cancel_delayed_work_sync by cancel_delayed_work).
Instead, a proper fix would imply modifying this critical section :
cpufreq.c: __cpufreq_remove_dev()
...
if (cpufreq_driver->target)
__cpufreq_governor(data, CPUFREQ_GOV_STOP);
unlock_policy_rwsem_write(cpu);
To make sure the __cpufreq_governor() callback is not called with rwsem
held. This would allow execution of cancel_delayed_work_sync() without
being nested within the rwsem.
Applies on top of the 2.6.30-rc5 tree.
Required to remove circular dep in teardown of both conservative and
ondemande governors so they can use cancel_delayed_work_sync().
CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
unneeded.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
CC: Ben Slusky <sluskyb@paranoiacs.org>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
arch/x86/kernel/cpu/cpufreq/powernow-k7.c:172: warning: 'invalidate_entry' defined but not used
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Some atom procs don't do freq scaling (such as the atom 330 on my own
littlefalls2 board). By adding the atom family here, we at least get
the benefit of passive cooling in a thermal emergency. Not sure how
to see that its actually helping any, but the driver does bind and
claim its functioning on my atom 330.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Dave Jones <davej@redhat.com>
The watchdog code currently hardcodes the base address
of the timer its using. To support new SoCs, make it
support timers at any address. Use the soc_info structure
to do this.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The davinci timer code currently hardcodes the timer register
base addresses, the timer irq numbers, and the timers to use
for clock events and clocksource. This won't work for some
a new SoC so put those values into the soc_info structure
and set them up in the SoC-specific files.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Use the SoC infrastructure to hold the interrupt controller
information (i.e., base address, default priorities,
interrupt controller type, and the number of IRQs).
The interrupt controller base, although initially put
in the soc_info structure's intc_base field, is eventually
put in the global 'davinci_intc_base' so the low-level
interrupt code can access it without a dereference.
These changes enable the SoC default irq priorities to be
put in the SoC-specific files, and the interrupt controller
to be at any base address.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The pinmux register base and setup can be different for different
SoCs so move the pinmux reg base, pinmux table (and its size) to
the SoC infrastructure.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The current code to support the DaVinci Power and Sleep Controller (PSC)
assumes that there is only one controller. This assumption is no longer
valid so expand the support to allow greater than one PSC.
To accomplish this, put the base addresses for the PSCs in the SoC
infrastructure so it can be referenced by the PSC code. This also
requires adding an extra parameter to davinci_psc_config() to specify
the PSC that is to be enabled/disabled.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
All of the davinci SoCs need to call davinci_clk_init() so
put the call in the common init routine.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The Davinci cpu_is_davinci_*() macros use the SoC part number
and variant retrieved from the JTAG ID register to determine the
type of cpu that the kernel is running on. Currently, the code to
read the JTAG ID register assumes that the register is always at
the same base address. This isn't true on some newer SoCs.
To solve this, have the SoC-specific code set the JTAG ID register
base address in soc_info structure and add a 'cpu_id' member to it.
'cpu_id' will be used by the cpu_is_davinci_*() macros to match
the cpu id. Also move the info used to identify the cpu type into
the SoC-specific code to keep all SoC-specific code together.
The common code will read the JTAG ID register, search through
an array of davinci_id structures to identify the cpu type.
Once identified, it will set the 'cpu_id' member of the soc_info
structure to the proper value and the cpu_is_davinci_*() macros
will now work.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Create a structure to encapsulate SoC-specific information.
This will assist in generalizing code so it can be used by
different SoCs that have similar hardware but with minor
differences such as having a different base address.
The idea is that the code for each SoC fills out a structure
with the correct information. The board-specific code then
calls the SoC init routine which in turn will call a common
init routine that makes a copy of the structure, maps in I/O
regions, etc.
After initialization, code can get a pointer to the structure
by calling davinci_get_soc_info(). Eventually, the common
init routine will make a copy of all of the data pointed to
by the structure so the original data can be made __init_data.
That way the data for SoC's that aren't being used won't consume
memory for the entire life of the kernel.
The structure will be extended in subsequent patches but
initially, it holds the map_desc structure for any I/O
regions the SoC/board wants statically mapped.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution
Module (EVM.)
Original support done by Sudhakar Rajashekhara.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
In addition, add board support for the DM355 Evaluation Module (EVM)
and the DM355 Leopard board.
Original DM355 EVM support done by Sandeep Paulraj, with significant
updates and improvements by David Brownell. DM355 Leopord support
done by Koen Kooi.
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Add support for Texas Instuments Common Platform Interrupt Controller
(cp_intc) used on DA830/OMAP-L137.
Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Mark Greer <mgreer@mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The davinci pre-kernel boot code assumes that all platforms use the
same UART base address for the console. That assumption is not longer
valid with some newer SoCs so determine the console UART base address
from the machine number passed in from bootloader.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch defines debug macros for low-level debugging for Davinci
based platforms
Tested on :
- DM644x DaVinci EVM
- DM646X DaVinciHD EVM
- DM355 EVM
This patch attempts to solve the low-level debug issue in DM646x. The
UART on DM646x SoC allows only 32-bit access. The existing
debug-macro.S uses the macros from debug-8250.S file. This led to
garbage serial out in the case of DM646x.
The inclusion of debug-8250.S does not allow for run time fix for this
issue. There are compile time errors due to multiple definitions of
the macros. Also when building a single image for multiple DaVinci
Platforms, the ifdefs cannot be relied upon.
The solution below does not include the debug-8250.S file and defines
the necessary macros. This solution was arrived at after observing
that word access does not affect the low-level debug messages on
DM644x/DM355.
The other approach to this issue is to use the UART module information
available in the peripheral registers to decide the access
mechanism. But this will have to be done for every access of UART
specifically for DM646x. Also this calls for a modification of the
debug-8250.S file.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch seems to get me much more reliable performance using the
GPIO banked interrupts on dm355 for the dm9000 driver.
Changes include:
- init GPIO handling along with normal GPIO init
- mask the level-sensitive bank IRQ during handling
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Fix two IRQ triggering bugs affecting GPIO IRQs:
- Make sure enabling with IRQ_TYPE_NONE ("default, unspecified")
isn't a NOP ... default to both edges, at least one must work.
- As noted by Kevin Hilman, setting the irq trigger type for a
banked gpio interrupt shouldn't enable irqs that are disabled.
Since GPIO IRQs haven't been used much yet, it's not clear these
bugs could have affected anything. The few current users don't
seem to have been obviously suffering from these issues.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
On Mon, 25 May 2009 18:33:28 +0200
Valentin Longchamp <valentin.longchamp@epfl.ch> wrote:
> Hello,
>
> I have updated my mxc git tree and given a compilation spin to your
> board support and I have comments. See below.
>
>
> What's the point of declaring this new function, if all it does is
> calling the already existing one ? Furthermore, in the current
> mxc-master tree, mxc_map_io() does not exist anymore, it should be
> mx31_map_io (this breaks compilation for your board).
>
This patch solve those two issues. Until now i based my patches to
vanilla tree. This evening I cloned the mxc-master tree so i could
update the armadillo 500 support within recent platform changes.
The patch:
From e986a8dc262e5292350d95bf65ead75baf3272d7 Mon Sep 17 00:00:00 2001
From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Date: Mon, 25 May 2009 22:24:03 +0200
Subject: [PATCH] Armadillo 500 removing useless function armadillo5x0_map_io
and use machine specific io mapping
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This adds support for the SMSC911x chip found on the lilly-1131 module.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Support code for lilly-1131 is implemented in a module/baseboard
fashion. All code specific to peripherals found on the development board
will go to this file.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds basic support for INCO startec's LILLY-1131 iMX31 based
modules. The module needs a baseboard support to work which will be
added in the next patch.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.
The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.
Signed-off-by: David Dillow <dave@thedillows.org>
Tested-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
For relocatable 32bit kernels, boot/compressed/relocs.c processes
relocation entries in the kernel image and appends it to the kernel
image such that boot/compressed/head_32.S can relocate the kernel.
The kernel image is one statically linked object and only uses two
relocation types - R_386_PC32 and R_386_32, of the two only the latter
needs massaging during kernel relocation and thus handled by relocs.
R_386_PC32 is ignored and all other relocation types are considered
error.
When the target of a relocation resides in a discarded section,
binutils doesn't throw away the relocation record but nullifies it by
changing it to R_386_NONE, which unfortunately makes relocs fail.
The problem was triggered by yet out-of-tree x86 stack unwind patches
but given the binutils behavior, ignoring R_386_NONE is the right
thing to do.
The problem has been tracked down to binutils behavior by Jan Beulich.
[ Impact: fix build with certain binutils by ignoring R_386_NONE ]
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jan Beulich <JBeulich@novell.com>
Cc: Ingo Molnar <mingo@elte.hu>
LKML-Reference: <4A1B8150.40702@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This patch fixes ssthresh accounting issues in tcp_vegas when cwnd decreases
Signed-off-by: Doug Leith <doug.leith@nuim.ie>
Signed-off-by: David S. Miller <davem@davemloft.net>
Changeset ca17584bf2 ("mac8390: update
to net_device_ops") broke mac8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in mac8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c. They seem to be of no value since
COMPAT_NET_DEV_OPS is going away soon.
Tested with a Kinetics EtherPort card.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
