ar900*_init_mode_regs needs to be called before RF banks are allocated,
otherwise the storage size of RF banks isn't known. This patch fixes
a memory overrun that can show up as a crash on unloading the module.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Ulrich Kunitz <kune@deine-taler.de>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Stefano Brivio <stefano.brivio@polimi.it>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Kalle Valo <kvalo@qca.qualcomm.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Samuel Ortiz <samuel@sortiz.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
CC: Jes Sorensen <jes@trained-monkey.org>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
regardless of what the runtime chainmask is.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The kbuild test robot reports the following warning with x86_64-randconfig-x955:
warning: (RTL8192CE && RTL8192SE && RTL8192DE && RTL8723AE && RTL8192CU) selects
RTLWIFI which has unmet direct dependencies (NETDEVICES && WLAN &&
(RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE))
This warning was introduced in commit a290593, "rtlwifi: Modify files for addition
of rtl8723ae", and is d ue to a missing dependence of RTLWIFI on RTL8723AE.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: kbuild test robot <fengguang.wu@intel.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Christoph Paasch found netxen could trigger a BUG in its dismantle
phase, in netxen_release_tx_buffer(), using full size TSO packets.
cmd_buf->frag_count includes the skb->data part, so the loop must
start at index 1 instead of 0, or else we can make an out
of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]
Christoph provided the fixes in netxen_map_tx_skb() function.
In case of a dma mapping error, its better to clear the dma fields
so that we don't try to unmap them again in netxen_release_tx_buffer()
Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Cc: Sony Chacko <sony.chacko@qlogic.com>
Cc: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
The last update to the Ethernet HowTo (over 10 years ago) listed this:
------------------------
SEEQ 8005
Status: Obsolete, Driver Name: seeq8005
There is little information about the card included in the driver,
and hence little information to be put here. If you have a question,
you are probably best trying to e-mail the driver author as listed
in the source.
It was marked obsolete as of the 2.4 series kernels.
------------------------
If it was obsolete over a decade ago, the situation can not have
improved with the passage of time, so let us act on that. Even with
today's improved search engines, I was unable to locate any real
meaningful information on the ISA implementation of this rare chip.
There are ARM and SGI variants of the driver in tree, but they do
not depend on the original x86 driver source or header file. We
leave those non-x86 drivers to be deleted by the arch maintainers
when they decide to expire those legacy platforms as a whole.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This is another one that makes sense to target for obsolescence, since
it (a)appeared pre-1995, and (b)was rather rare, and (c)did not
really have any statistically significant active linux user base.
Removing this ISA 10Mbit driver support is unlikely to be even noticed
by the user base of 3.9+ linux kernels, especially when the documentation
clearly indicates the vintage with this text:
"...designed to work with all kernels > 1.1.33"
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These are old ISA 10Mbit cards from the 1st 1/2 of the 1990s and
required manual jumper settings in order to configure them. Here
we remove them on the premise that they are no longer used in any
modern 3.9+ kernels.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This is an area I know all too well, after being author of several 8390
drivers, and maintainer of all 8390 drivers during a large part of their
active lifecycle.
To that end, I can say this with a reasonable degree of confidence.
The drivers deleted here represent the earliest (as in early 1990)
hardware and/or rare hardware. The remaining hardware not deleted
here is the more modern/sane of the lot, with ISA-PnP and jumperless
"soft configuration" like the wd and smc cards had.
The original ne2000 driver (ne.c) gets a pass at this time since
AT/LANTIC based cards that could be both ne2000 or wd-like (with
shared memory) and with jumperless configuration were made in the
mid to late 1990's, and performed reasonably well for their era.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This is another driver for relatively rare 10Mbit hardware that
originated in the early 1990's. So we select it for removal at
this point in time as well.
Cc: Mika Kuoppala <miku@iki.fi>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These Fujitsu MB86965 based ISA 10Mbit cards were another of the
relatively rare cards dating from the early 1990s that for one reason
or another didn't seem to get a lot of use in linux. So we retire it
now with a reasonable degree of confidence that it won't impact anyone.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These cards were only available in 8bit format, and in addition
they only had AUI and BNC(10-Base2) interfaces (i.e. no RJ-45).
In fact, they are so rare, that an internet search on these old
cards almost comes up empty, unless the "Micom interlan" name
is used.
This puts them in the equivalent domain as the 3c501, so there
should be no strong opposition to the driver removal, as nobody
is seriously using 3.9+ with 8 bit ISA hardware.
In doing so, the whole "ethernet/racal" category becomes empty,
so we clean up the Makefile/Kconfig and subdir appropriately.
Cc: Andreas Mohr <andi@lisas.de>
Cc: Jan-Pascal van Best <janpascal@vanbest.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Like the other drivers that were in the ISA i825xx family, the ni52
was rather rare, not widely used, and hence perhaps not as reliable
as the more mainstream ISA drivers that were heavily used. Given
that, it is chosen for retirement at this time as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This driver supported early to mid 1990's Zenith laptops, of the
2" thick variety. The driver was already dead 10+ years ago, but
we see this in the source:
----------------
/* 10/2002
[...]
Tested on a vintage Zenith Z-Note 433Lnp+. Probably broken on
anything else. Testers (and detailed bug reports) are welcome :-).
----------------
To clarify, a 433 translates into a 486 at 33MHz, and a system with
a default of 4MB RAM. I can't fault the noble effort to keep things
working a decade ago, but at this point in time, there is no valid
justification to continue carrying this driver along.
Note that there is no associated Space.c cleanup here since this
driver was using module_init to hook itself in.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These old drivers should not be confused with the very common PCI
cards that are supported by e100.c -- these older 10Mbit ISA only
drivers were not as commonly used as some of the other ISA drivers,
simply due to hardware availability and pricing.
Given the rarity of the hardware, and the subsequent less extensive
use of the drivers, it makes sense to obsolete them at this point
in time, along with other rare/experimental ISA drivers.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
For those of us who were around in the early to mid 1990's, we
will remember that the i825xx ethernet support was not something
that was considered sufficiently vetted for 24/7 use.
Folks might be inclined to use *functional* ISA hardware on some
near expired P3 ISA machines for dedicated workhorse applications,
but the odds of using (and relying on) one of these old/experimental
drivers is essentially nil. So lets remove them.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
The parallel port is largely replaced by USB, and even in the
day where these drivers were current, the documented speed was
less than 100kB/s. Let us not pretend that anyone cares about
these drivers anymore, or worse - pretend that anyone is using
them on a modern kernel.
As a side bonus, this is the end of legacy parallel port ethernet,
so we get to drop the whole chunk relating to that in the legacy
Space.c file containing the non-PCI unified probe dispatch.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
It was amusing that linux was able to make use of this 1980's
technology on machines long past its intended lifespan, but
it probably should go now.
To set some context, the 3c501 was designed in the 1980's to be
used on 8088 PC-XT 8bit ISA machines. It was built using a large
number of discrete TTL components and truly looks like a relic
of the ancient past before large scale integration was common.
But from a functional point of view, the real issue, as stated
in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
only do one thing at a time -- while you are removing one packet
from the single-packet buffer it cannot receive another packet,
nor can it receive a packet while loading a transmit packet."
You know things are not good when the Kconfig help text suggests
you make a cron job doing a ping every minute.
Hardware that old and crippled is simply not going to be used by
anyone in a time where 10 year old 100Mbit PCI cards (that are
still functional) are largely give-away items.
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
This driver was specific to a "professional workstation" line
of products from around 1993 that used the i82596 ethernet chip
as an on-board ethernet solution.
With a 486 processor, and the premium top of the line model maxing
out at a clock speed of 50MHz, we can safely retire this support.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
The Apricot was a 486 PC with 4MB RAM, and an on-board ethernet
via an intel i82596 hard-wired to i/o 0x300.
Those who were using linux in the 1990's will recall that the
i82596 driver was not one of the more stable or widely used
drivers of its day. Combine that with the extremely limited
resources of the platform, and it is truly time to expire the
support for this thing.
There are some old m68k targets who were also using this chip,
so rather than poll the m68k user base, we simply cut out the
x86/Apricot support here in this commit.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Delete successive tests to the same location. rc was previously tested and
not subsequently updated. efx_phc_adjtime can return an error code, so the
call is updated so that is tested instead.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Infineon(now Intel) HSPA Modem platform NCM cannot support ARP.
we can define a new common structure wwan_noarp_info.
Then more similiar NO ARP devices can be handled easily
Signed-off-by: Wei Shuai <cpuwolf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We do have some USB net devices, which cannot do ARP.
so we can introduce a new flag FLAG_NOARP, then client drivers
can easily handle this kind of devices
Signed-off-by: Wei Shuai <cpuwolf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit bbc8d92 (net: cdc_ncm: add Huawei devices) implemented
support for devices with a single combined control and data
interface. Fix up the error path so that we do not double
release such interfaces in case of probing failures.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
