When i2400m_bootrom_init() fails to put the device into a state of
being ready to accept firmware, the driver was currently trying to
reset it if it failed to do so. This is not too useful; as part of
trying to put the device in the right state a few resets have already
been tried.
At this point, things are probably fried out and an extra reset might
do more harm than good (for example causing reseting of other
functions in the same composite device).
So it is left up to the callers to determine the error path to take
(at the end this is always i2400m_setup(), who depending on how many
retries are left, might give up on the device).
From a fix by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This change moves the table of "pokes" performed on the device at boot
time to the bus specific portion of the driver.
Different models of the i2400m device supported by this driver require
different poke tables, thus having a single table that works for all
is impossible. For that, the table is moved to the bus-specific
driver, who can decide which table to use based on the specifics of
the device and point the generic driver to it.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
The code that sets up the i2400m (firmware load and general driver
setup after it) includes a couple of retry loops.
The SDIO device sometimes can get in more complicated corners than the
USB one (due to its interaction with other SDIO functions), that
require trying a few more times.
To solve that, without having a failing USB device taking longer to be
considered dead, allow the retry counts to be specified by the
bus-specific driver, which the general driver takes as a parameter.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When a device reboot happens when we are under probe, with init_mutex
taken, make sure we can recover. Have dev_reset_handle set boot mode
and i2400m_msg_to_dev() will see it and fail gracefully instead of
timing out.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When the TX FIFO filled up and i2400m_tx_new() failed to allocate a
new TX message header, a missing check for said condition was causing a
kernel oops when trying to dereference a NULL i2400m->tx_msg pointer.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_dev_shutdown() tried to reset the device to put it in a known
state before shutting down.
But that turned out to be pointless. We reach this case in two paths:
1 - when the device resets, to clean up state
2 - when the driver is unloaded, for the same
however, in both cases it is pointless; in (1) the device is already
reset, why do it again? in (2) we can't -- the USB stack, for example,
doesn't allow communicating with the device when the driver is being
unbound and if the device is disconnected, the device is gone already.
So just remove it. Leave the function as a placeholder for future
cleanups that will be done from data allocated by the driver during
device operation.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_tx_skip_tail() needs to handle the special case of being called
when the tail room that is left over in the FIFO is zero.
This happens when a TX message header was opened at the very end of
the FIFO (without payloads). The i2400m_tx_close() code already marked
said TX message (header) to be skipped and this function should be
doing nothing.
It is called anyway because it is part of a common "corner case" path
handling which takes care of more cases than only this one.
The tail room computation was also improved to take care of the case
when tx_in is at the end of the buffer boundary; tail_room has to be
modded (%) to the buffer size. To do that in a single well-documented
place, __i2400m_tx_tail_room() is introduced and used.
Treat i2400m->tx_in == 0 as a corner case and handle it accordingly.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In some situations, when a new TX message header is started, there
might be no space for data payloads. In this case the message is left
with zero payloads and the i2400m_tx_close() function has just to mark
it as "to skip". If it tries to go ahead it will overwrite things
because there is no space to add padding as defined by the
bus-specific layer. This can cause buffer overruns and in some stress
cases, panics.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The constant is being use as an alignment factor, not as a padding
factor; made reading/reviewing the code quite confusing.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This reset type causes the WiMAX function to be disabled and
re-enabled, which will force the WiMAX device to reset and enter boot
mode.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
By mistake, the BUG_ON() check was left in there and it will fail when
called if i2400m->work_queue is still not setup.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
RX support is the only user of the work-queue, to process
reports/notifications from the device. Thus, it needs the work queue
to be initialized first.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reported and fixed by Cindy H Kao.
When the device is stopped __i2400m_dev_stop() stops the network
queue.
However, when this is done in the middle of heavy network operation,
when the bus-specific subdriver is still wrapping up and it reports a
sent TX transaction with _tx_msg_sent() right after the device was
stopped, the queue was being started again, which was causing a stream
of oopsen and finally a panic.
In any case, said call has no place there. It's a left over from an
early implementation that was discarded later on.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The i2400m driver waits for the device to report being ready for
entering power save before asking it to do so. This module parameter
allows control of said operation; if disabled, the driver won't ask
the device to enter power save mode.
This is useful in setups where power saving is not so important or
when the overhead imposed by network reentry after power save is not
acceptable; by combining this with parameter 'idle_mode_disabled', the
driver will always maintain both the connection and the device in
active state.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The WAKE_MCAST bit is tested twice, the first should be WAKE_UCAST.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Jie Yang <jie.yang@atheros.com>
Cc: Jay Cliburn <jcliburn@gmail.com>
Cc: Chris Snook <csnook@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a configurable Descriptor Skip Length for systems that lack cache
coherence.
(akpm: I think this should be done as a module parameter, not a
compile-tinme option)
Signed-off-by: Risto Suominen <Risto.Suominen@gmail.com>
Cc: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13348
akpm: the reporter disappeared, so I typed it in again.
It is not possible to make clone of tagged VLAN interface to be used as
mac-based vlan interfave.
How reproducible:
Use any 802.1q tagged vlan interface, e.g. eth2.700 and clone it:
ip link add link eth2.700 address 00:04:75:cb:38:09 macvlan0 type macvlan
ip link set dev macvlan0 up
ip addr add 10.195.1.1/24 dev macvlan0
So far, so good. Now try to ping anything via macvlan0:
ping 10.195.1.2
Actual results:
For every attempted packet tx kernel writes to console:
------------[ cut here ]------------
WARNING: at net/8021q/vlan_dev.c:254 vlan_dev_hard_header+0x36/0x126 [8021q]()
Hardware name: M22ES
Modules linked in: arptable_filter arp_tables bridge veth macvlan arc4 ecb
ppp_mppe ppp_async crc_ccitt ppp_generic slhc autofs4 sunrpc 8021q garp stp
ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp
x_tables dm_mirror dm_region_hash dm_log dm_multipath dm_mod sbs sbshc lp
floppy snd_intel8x0 joydev snd_seq_dummy snd_intel8x0m snd_ac97_codec
ide_cd_mod ac97_bus snd_seq_oss cdrom snd_seq_midi_event serio_raw snd_seq
snd_seq_device snd_pcm_oss snd_mixer_oss parport_pc snd_pcm parport battery
8139cp snd_timer i2c_sis96x ac button snd rtc_cmos rtc_core 8139too soundcore
rtc_lib mii i2c_core pcspkr snd_page_alloc pata_sis libata sd_mod scsi_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: ip_tables]
Pid: 0, comm: swapper Tainted: G W 2.6.29.3 #1
Call Trace:
[<c0425f48>] warn_slowpath+0x60/0x9f
[<c0425f6f>] warn_slowpath+0x87/0x9f
[<dffb850d>] vlan_dev_hard_header+0x0/0x126 [8021q]
[<dffb8543>] vlan_dev_hard_header+0x36/0x126 [8021q]
[<dffb850d>] vlan_dev_hard_header+0x0/0x126 [8021q]
[<df83155d>] macvlan_hard_header+0x3c/0x47 [macvlan]
[<df831521>] macvlan_hard_header+0x0/0x47 [macvlan]
[<c062bf3f>] arp_create+0xef/0x1ff
[<c062c08c>] arp_send+0x3d/0x54
[<c062c916>] arp_solicit+0x16c/0x177
[<c05fadd2>] neigh_timer_handler+0x227/0x269
[<c05fabab>] neigh_timer_handler+0x0/0x269
[<c042ce4d>] run_timer_softirq+0xf0/0x141
[<c0429e5a>] __do_softirq+0x76/0xf8
[<c0429de4>] __do_softirq+0x0/0xf8
<IRQ> [<c044fb67>] handle_level_irq+0x0/0xad
[<c0429db7>] irq_exit+0x35/0x62
[<c04046bb>] do_IRQ+0xdf/0xf4
[<c04035a7>] common_interrupt+0x27/0x2c
[<c04079c5>] default_idle+0x2a/0x3d
[<c0401bb6>] cpu_idle+0x57/0x70
Macvlan driver always uses standard ethernet header length for all types
of interface to which it is linked. This patch fixes this problem.
Reported-by: <sg.tweak@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Restore support for cards with MII-lacking PHYs as compared to removed
pre-2.6.29 eepro100 driver: use full low-level MII I/O access abstraction
by providing clean PHY-specific mdio_ctrl() functions for either standard
MII-compliant cards, slightly special ones or non-MII PHY ones.
We now have another netdev_priv member for mdio_ctrl(), thus we have some
array indirection, but we save some additional opcodes for specific
phy_82552_v handling in the common case.
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Andreas Mohr <andi@lisas.de>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Cc: John Ronciak <john.ronciak@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Always enable rfkill since the ifdefs in the code is not really worth
the Kconfig option. Also fix a few code style things, and remove the
usage of the ah_gpio[] array so we can remove it later.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch along with my previous patch in mac80211 "Fix the
way ADDBA count..", fixes hang in tx when connected to an HT
AP which rejects/times out on addba req.
AGGR_ADDBA_PROGRESS should be cleared in aggr state when addba
negotiation is terminated due to either addba response is timed out
or addba is denied by the AP. With out clearing this bit,
all frames are queued onto s/w queue for getting tx'd as aggr and
will never be scheduled onto hw queue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add automagic feature flags, so the firmware can tell the driver
about supported features and the driver can switch features on/off as
needed.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This ports the b43/legacy rfkill code to the new API offered
by cfg80211 and thus removes a lot of useless stuff.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch introduces initial rfkill support for the ath5k driver
based on rfkill support in the cfg80211 framework.
All rfkill related code is separated into newly created rfkill.c.
Changes to existing code are minimal:
* added a new data structure ath5k_rfkill to the ath5k_softc structure
* inserted calls to HW rfkill init/deinit routines
* ath5k_intr() has been extended to handle AR5K_INT_GPIO interrupts
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is a back-port from aggregation testing code.
In the past, we didn't limit the amount of active tx urbs.
However, ar9170 only has a limited buffer reserved for
pending data frames.
This wasn't much of a problem with the slower 802.11b/g.
We simply stopped the full queue and moved on to something different
in the mean time. But - as you guessed it - this simple approach
stands in way for a decent aggregation implementation.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds new commands that the original firmware will not send
but we can use them to debug firmware.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix possible unaligned u32 access in b43_generate_plcp_hdr().
Unaligned data is read/write with a u32 pointer instead of using the
packed structure. Some versions of gcc ignore the "packed" attribute, if the
structure element is accessed through a local pointer.
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes the dependency on GPIO framework and lets the SPI host
driver handle the chip select. The SPI host driver is required to keep
the CS active for the entire message unless cs_change says otherwise.
This patch collects the two/three single SPI transfers into a message.
Also the delay in read path in case use_dummy_writes are not used is
moved into the SPI host driver.
Tested-by: Mike Rapoport <mike@compulab.co.il>
Tested-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver used to be named rndis_wext before inclusion to upstream. Since
rndis_wlan is being converted to cfg80211, use of rndis_wext* names
can be confusing. So rename all rndis_wext to rndis_wlan (as should
have been when driver was renamed).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Capitalize enum labels as told in Documents/CodingStyle.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This ports the iwlwifi rfkill code to the new API offered by
cfg80211 and thus removes a lot of useless stuff. The soft-
rfkill is completely removed since that is now handled by
setting the interfaces down.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to "Documentation/printk-formats.txt", if the type is
dependent on a config option for its size, like resource_size_t,
we should use a format specifier of its largest possible type and
explicitly cast to it.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently we support only PCIe NIC functions zero and one, and FCoE
functions as 3 and 4. Future configurations can mix these up in any
fashion.
This patch removes the 0-1 dependancy and allows usage of any of the 4
functions. We also find the alternate NIC function (if exist) and
determine our port number based on the comparison of the two functions:
Lower function number gets first port, higher function gets second port.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Extract either manufacturer or Bladecenter Open Fabric
Manager (BOFM) MAC address. BOFM may indicate an
alternate MAC address. This patch honors that request
by extracting the MAC address from a different
flash location if a flag is set.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The max frame size register is set higher than the MTU to
accomodate FCoE frames.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Not necessary if hardware supports 65536 as it's the default setting.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no need to check if a pointer is NULL before calling
vfree(), since vfree() function already check for it.
Signed-off-by: Breno Leitão <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Include offloaded FCoE data into total rx/tx statistics for 82599 so they
are properly reflected by ethtool or ifconfig.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ethtool is a standard way of getting information about
ethernet interfaces. We enhance ethtool kernel interface
& e1000e to make the MDI-X status readable via ethtool in
userspace.
Signed-off-by: Chaitanya Lala <clala@riverbed.com>
Signed-off-by: Arthur Jones <ajones@riverbed.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
e1000e_config_collision_dist() sets tctl, but subsequently tctl is
overwritten. It seems to me that as things stand the call to
e1000e_config_collision_dist() has no effect and should either be
removed or moved down a little bit. This kernel patch takes the latter
option.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Phy corruption has been observed on 2-port 82571 adapters, and is root-caused
to lack of synchronization between the 2 driver instances, which conflict
when attempting to access the phy via the single MDIC register.
A semaphore exists for this purpose, and is now used on these designs. Because
PXE &/or EFI boot code (which we cannot expect to be built with this fix) may
leave the inter-instance semaphore in an invalid initial state when the driver
first loads, this fix also includes a one-time (per driver load) fix-up of the
semaphore initial state.
Signed-off-by: dave graham <david.graham@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fakehard is a really simple driver implementing only necessary
callbacks and serves the role of an example of driver for HardMAC
IEEE 802.15.4 device.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Sergey Lapin <slapin@ossfans.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This driver does not indicate support for frag lists.
Furthermore, even if it did, the code is walking the frag
lists incorrectly. The idiom is:
for (iter = skb_shinfo(skb)->frag_list; iter; iter = iter->next)
but it's doing:
for (iter = skb_shinfo(skb)->frag_list; iter;
iter = skb_shinfo(iter)->frag_list)
which would never work. And this proves that this driver never
saw an SKB with active frag lists.
So just remove the code altogether and the driver TX path becomes
much simpler.
Signed-off-by: David S. Miller <davem@davemloft.net>
A driver overhaul on 29 Feb 2000 (!) broke locking around fiddling with
the tx descriptor ring in start_xmit(); a follow-on "fix" removed the
broken remnants altogether. Here's a patch to restore proper locking in
the function -- the complement in the interrupt handler has been correct
all the time.
This *may* have been the reason for the occasional confusion of the chip
-- triggering a tx timeout followed by a chip reset sequence -- seen on
R4k-based DECstations with the onboard Ethernet interface. Another theory
is the confusion is due to an unindentified problem -- perhaps a silicon
erratum -- associated with the variation of the MT ASIC used to interface
the R4k CPU to the rest of the system on these computers; with its
aggressive write-back buffering the design is particularly weakly ordered
when it comes to MMIO (in the absence of ordering barriers uncached reads
are allowed to bypass earlier uncached writes, even if to the same
location), which may trigger all kinds of corner cases in peripheral
hardware as well as software.
Either way this piece of code is buggy.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
