Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that the original SMC_USE_PXA_DMA specific code will always being
built if CONFIG_ARCH_PXA is defined, so to make this part of the code
to be PXA public, and still prevent it from being built if support of
PXA is not selected.

A SMC91X_USE_DMA flag is added to the platform data to allow platform
to choose its usage of DMA. Note this flag itself is so named to be
generic enough (assuming other platforms can also use DMA).

It keeps backward compatibility to set the SMC91X_USE_DMA flag if
SMC_USE_PXA_DMA is still defined.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now one can use the following code

  #define SMC_IO_SHIFT	lp->io_shift

to make SMC_IO_SHIFT a variable. This, however, will slightly increase
the CPU overhead and have negative impact on the network performance.
The tradeoff is, this can be specified in the smc91x platform data so
that multiple boards support can be built in a single zImage.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

And also favors the usage of SMC91X_NOWAIT over the hardcoded SMC_NOWAIT
by converting "nowait" (module parameter overridable) to platform flag.

There are several possibilities:

  1. platform data present - preferred and use as is
  2. platform data absent  - use "nowait", it can be:
       a. SMC_NOWAIT if defined
       b. default to 0 if SMC_NOWAIT isn't defined
       c. overriden by module parameter
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Let's simplify the logic and avoid confusion, the use of SMC91X_USE_*
is favored than SMC_CAN_USE_*, if platform data isn't given, convert
the hardcoded SMC_CAN_USE_* to SMC91X_USE_*.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

IRQ trigger type can be specified in the IRQ resource definition by
IORESOURCE_IRQ_*, we need only one way to specify this.

This also fixes the following small issue:

To allow dynamic support for multiple platforms, when those relevant
macros are not defined for one specific platform, the default case
will be:

	- SMC_DYNAMIC_BUS_CONFIG defined
	- and SMC_IRQ_FLAGS = IRQF_TRIGGER_RISING

While if "irq_flags" is missing when defining the smc91x_platdata,
usually as follows:

  static struct smc91x_platdata xxxx_smc91x_data = {
	.flags	= SMC91X_USE_XXBIT,
  };

The lp->cfg.irq_flags will always be overriden by the above structure
(due to a memcpy), thus rendering lp->cfg.irq_flags to be "0" always.
(regardless of the default SMC_IRQ_FLAGS or IORESOURCE_IRQ_* flags)

Fixes this by forcing to use IORESOURCE_IRQ_* flags if present, and
make the only user of smc91x_platdata.irq_flags (renesas/migor) to
use IORESOURCE_IRQ_*.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC.

AT91sam9g20 is an evolution of the at91sam9260 with a faster clock
speed.
We created a new board for this device but based the chip support
directly on 9260 files with little updates.
Here is the chip page on Atmel wabsite:
http://atmel.com/dyn/products/product_card.asp?part_id=4337Signed-off-by: NSedji Gaouaou <sedji.gaouaou@atmel.com>
Signed-off-by: NJustin Waters <justin.waters@timesys.com>
Acked-by: NAndrew Victor <linux@maxim.org.za>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

	is handled in board code
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix:
  drivers/net/arm/etherh.c:650: warning: unused variable `i'
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rewrite AID calculation in handle_pspoll() to avoid truncating bits.
Make hostap_80211_header_parse() static, don't export it.  Avoid
shadowing variables.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

DEBUG_EXTRA is reported to the kernel log by default, but DEBUG_EXTRA2
is not.  Unrelated WDS frames pollute the log unnecessarily.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAndre Haupt <andre@bitwigglers.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

clock is already cpu-endian (see le32_to_cpu slightly before), so
le64_to_cpu doesn't make much sense.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes a circular locking dependency in the workqueue handling.
The interface work task uses the mac80211 function
ieee80211_iterate_active_interfaces() which grabs the RTNL lock.

However when the interface is brough down, this happens under the RTNL
lock as well, this causes problems because mac80211 will flush the workqueue
during the ifdown event. This causes mac80211 to wait until the driver has
completed all work which can't finish because it is waiting on the RTNL lock.

This is fixed by moving rt2x00 workqueue tasks on a different workqueue,
this workqueue can be flushed when the ieee80211_hw structure is removed
by the driver (when the driver is unloaded) which does not happen under the
RTNL lock.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

dev_close() must be called holding the RTNL.  Compile-tested only.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

dev_close() must be called holding the RTNL.  Compile-tested only.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

s2io has IOMMU overflow checking, but unfortunately it is wrong.

It didn't use the standard macros, which meant that it only worked
on POWER and SPARC because only those define DMA_ERROR_CODE. Convert it to
use the standard macros instead.

I also commented two more bugs in the IOMMU handling. It assumes
that 0 DMA addresses cannot happen, but that's not true in all IOMMU setups.
The information if a buffer has been already mapped needs to be stored
elsewhere.

Didn't fix those because it needs careful checking of the buffer handling
by the maintainers.

Cc: ram.vepa@neterion.com
Cc: santosh.rastapur@neterion.com
Cc: sivakumar.subramani@neterion.com
Cc: sreenivasa.honnur@neterion.com
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

When enabling TSO via ethool on e1000, it is possible to set
NETIF_F_TSO6 on hardware that does not support it.  Setting TSO via
ethtool now matches the settings used when the hardware is probed.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The E100 device can't work on current kernel (2.6.26-rc6) and will cause
kernel corruption on intel ixdp4xx.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

	PCI_DEVICE_CLASS sets .device and .vendor to PCI_ANY_DEV,
which overrides the effect of preceding PCI_DEVICE() and makes
all elements of netxen_pci_tbl[] identical.  Introduced in the
commit dcd56fdb.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Original Author: Michael Buesch <mb@bu3sch.de>

net, vortex: fix lockup

Ingo Molnar reported:

-tip testing found that Johannes Berg's "softirq: remove irqs_disabled
warning from local_bh_enable" enhancement to lockdep triggers a new
warning on an old testbox that uses 3c59x vortex and netlogging:

----->
    calling  vortex_init+0x0/0xb0
    PCI: Found IRQ 10 for device 0000:00:0b.0
    PCI: Sharing IRQ 10 with 0000:00:0a.0
    PCI: Sharing IRQ 10 with 0000:00:0b.1
    3c59x: Donald Becker and others.
    0000:00:0b.0: 3Com PCI 3c556 Laptop Tornado at e0800400.
    PCI: Enabling bus mastering for device 0000:00:0b.0
    initcall vortex_init+0x0/0xb0 returned 0 after 47 msecs
...
    calling  init_netconsole+0x0/0x1b0
    netconsole: local port 4444
    netconsole: local IP 10.0.1.9
    netconsole: interface eth0
    netconsole: remote port 4444
    netconsole: remote IP 10.0.1.16
    netconsole: remote ethernet address 00:19:xx:xx:xx:xx
    netconsole: device eth0 not up yet, forcing it
    eth0:  setting half-duplex.
    eth0:  setting full-duplex.
------------[ cut here ]------------
    WARNING: at kernel/softirq.c:137 local_bh_enable_ip+0xd1/0xe0()
    Pid: 1, comm: swapper Not tainted 2.6.26-rc6-tip #2091
     [<c0125ecf>] warn_on_slowpath+0x4f/0x70
     [<c0126834>] ? release_console_sem+0x1b4/0x1d0
     [<c0126d00>] ? vprintk+0x2a0/0x450
     [<c012fde5>] ? __mod_timer+0xa5/0xc0
     [<c046f7fd>] ? mdio_sync+0x3d/0x50
     [<c0160ef6>] ? marker_probe_cb+0x46/0xa0
     [<c0126ed7>] ? printk+0x27/0x50
     [<c046f4c3>] ? vortex_set_duplex+0x43/0xc0
     [<c046f521>] ? vortex_set_duplex+0xa1/0xc0
     [<c0471b92>] ? vortex_timer+0xe2/0x3e0
     [<c012b361>] local_bh_enable_ip+0xd1/0xe0
     [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40
     [<c0471b92>] vortex_timer+0xe2/0x3e0
     [<c014743b>] ? trace_hardirqs_on+0xb/0x10
     [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160
     [<c012f8b2>] run_timer_softirq+0x162/0x1c0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c012b361>] local_bh_enable_ip+0xd1/0xe0
     [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40
     [<c0471b92>] vortex_timer+0xe2/0x3e0
     [<c014743b>] ? trace_hardirqs_on+0xb/0x10
     [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160
     [<c012f8b2>] run_timer_softirq+0x162/0x1c0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c012b60a>] __do_softirq+0x9a/0x160
     [<c012b570>] ? __do_softirq+0x0/0x160
     [<c0106775>] call_on_stack+0x15/0x30
     [<c012b4f5>] ? irq_exit+0x55/0x60
     [<c0106e85>] ? do_IRQ+0x85/0xd0
     [<c0147391>] ? trace_hardirqs_on_caller+0xc1/0x160
     [<c0104888>] ? common_interrupt+0x28/0x30
     [<c08d8ac8>] ? mutex_unlock+0x8/0x10
     [<c08d8180>] ? _cond_resched+0x10/0x30
     [<c07a3be7>] ? netpoll_setup+0x117/0x390
     [<c0cbfcfe>] ? init_netconsole+0x14e/0x1b0
     [<c013d539>] ? ktime_get+0x19/0x40
     [<c0c9bab2>] ? kernel_init+0x1b2/0x2c0
     [<c0cbfbb0>] ? init_netconsole+0x0/0x1b0
     [<c0396aa4>] ? trace_hardirqs_on_thunk+0xc/0x10
     [<c0103f12>] ? restore_nocheck_notrace+0x0/0xe
     [<c0c9b900>] ? kernel_init+0x0/0x2c0
     [<c0c9b900>] ? kernel_init+0x0/0x2c0
     [<c0104aa7>] ? kernel_thread_helper+0x7/0x10
     =======================
---[ end trace 37f9c502aff112e0 ]---
    console [netcon0] enabled
    netconsole: network logging started
    initcall init_netconsole+0x0/0x1b0 returned 0 after 2914 msecs

looking at the driver I think the bug is real and the fix actually
is trivial.

vp->lock is also taken in hardware IRQ context, so we _have_ to always
use irqsafe locking. As we run in a timer with IRQs disabled,
we can simply use spin_lock.

Cc: <stable@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Fixes a sparse warning in a code block that's hidden under JUMBO_FRAME #ifdef.
Tested-by: NAndrew Savchenko <Bircoph@list.ru>
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Make jumbo frame support compile again. It was broken by the cleanup series
before the merge because the code is hidden under JUMBO_FRAME #ifdef.
Tested-by: NAndrew Savchenko <Bircoph@list.ru>
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Taking sizeof the result of sizeof is quite strange and does not seem to be
what is wanted here.

This was fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression E;
@@

- sizeof (
  sizeof (E)
- )
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NKomuro <komurojun-mbn@nifty.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

EEH is not recovering in a reasonable amount of time on PPC during
e1000e_down().
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

EEH is not recovering in a reasonable amount of time on PPC during
igb_down().
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

EEh is not recovering in a resonable amount of time on PPC during
ixgbe_down().
Signed-off-by: NPaul Larson <pl@us.ibm.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

On Rx FIFO overflow error, the controller consume a buffer descriptor
but currently the driver does not give it back to the controller.
This results unrecoverable 'Buffer List Exhausted' condition.  This
patch fix this problem by moving a "fbl_count--" line to proper place.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Call netif_carrier_off() before starting PHY device.  This is a
behavior before converting to generic PHY layer.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This patch modifies the band selection management when scanning, so
bands are now scanned according to HW band support.
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The usb_cache_mutex was not correctly released
under all circumstances. Both rt73usb as rt2500usb
didn't release the mutex under certain conditions
when the register access failed. Obviously such
failure would lead to deadlocks.

In addition under similar circumstances when the
bbp register couldn't be read the value must be
set to 0xff to indicate that the value is wrong.
This too didn't happen under all circumstances.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes a possible NULL pointer dereference in an error path of the
DMA allocation error checking code. This is also necessary for a future
DMA API change that is on its way into the mainline kernel that adds
an additional dev parameter to dma_mapping_error().
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes a possible MMIO access while the device is still down
from a suspend cycle. MMIO accesses with the device powered down
may cause crashes on certain devices.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
This will fix the resume hang.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>