From: Andrew Morton <akpm@linux-foundation.org>

gcc-3.4.4 on powerpc:

drivers/net/via-velocity.c:443: error: chip_info_table causes a section type conflict

on this one I had to remove the __devinitdata too.  Don't know why.

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gcc-3.4.4 on powerpc:

drivers/net/natsemi.c:245: error: natsemi_pci_info causes a section type conflict

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gcc-3.4.4 on powerpc:

drivers/net/typhoon.c:137: error: version causes a section type conflict

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

drivers/net/pppol2tp.c: In function `pppol2tp_seq_tunnel_show':
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 4)
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 5)
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 6)
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 7)
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 8)
drivers/net/pppol2tp.c:2295: warning: long long unsigned int format, __u64 arg (arg 9)
drivers/net/pppol2tp.c: In function `pppol2tp_seq_session_show':
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 5)
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 6)
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 7)
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 8)
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 9)
drivers/net/pppol2tp.c:2328: warning: long long unsigned int format, __u64 arg (arg 10)

Not all platforms implement u64 with unsigned long long.  eg: powerpc.

Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gcc-3.4.4 on powerpc:

drivers/net/bnx2.c:67: error: version causes a section type conflict

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Andrew Morton <akpm@linux-foundation.org>

gcc-3.4.4 on powerpc:

drivers/net/bnx2x.c:73: error: version causes a section type conflict

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

x25_asy does not take an ldisc reference before calling the flush method.
Fix it to use the helper function we provide.
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add architecture support for the MN10300/AM33 CPUs produced by MEI to the
kernel.

This patch also adds board support for the ASB2303 with the ASB2308 daughter
board, and the ASB2305.  The only processor supported is the MN103E010, which
is an AM33v2 core plus on-chip devices.

[akpm@linux-foundation.org: nuke cvs control strings]
Signed-off-by: NMasakazu Urade <urade.masakazu@jp.panasonic.com>
Signed-off-by: NKoichi Yasutake <yasutake.koichi@jp.panasonic.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As discussed on LKML some notion of 'function' is needed in
LED naming. This patch adds this to the documentation and
standardises existing LED drivers.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

Now that struct mlx4_buf.u is a struct instead of a union because of
the vmap() changes, there's no point in having a struct at all.  So
move .direct and .page_list directly into struct mlx4_buf and get rid
of a bunch of unnecessary ".u"s.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Since kernel virtual memory is not a problem on 64-bit systems, there
is no reason to use our own 2-layer page mapping scheme for large
kernel queue buffers on such systems.  Instead, map the page list to a
single virtually contiguous buffer with vmap(), so that can we access
buffer memory via direct indexing.
Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

I got the following oops during interface ifup. Unfortunately its not
easily reproducable so I cant say for sure that my fix fixes this
problem, but I am confident and I think its correct anyway:

   <2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234!
    <4>illegal operation: 0001 [#1] PREEMPT SMP
    <4>Modules linked in:
    <4>CPU: 0 Not tainted 2.6.24zlive-guest-07293-gf1ca1512-dirty #91
    <4>Process swapper (pid: 0, task: 0000000000800938, ksp: 000000000084ddb8)
    <4>Krnl PSW : 0404300180000000 0000000000466374 (vring_disable_cb+0x30/0x34)
    <4>           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
    <4>Krnl GPRS: 0000000000000001 0000000000000001 0000000010003800 0000000000466344
    <4>           000000000e980900 00000000008848b0 000000000084e748 0000000000000000
    <4>           000000000087b300 0000000000001237 0000000000001237 000000000f85bdd8
    <4>           000000000e980920 00000000001137c0 0000000000464754 000000000f85bdd8
    <4>Krnl Code: 0000000000466368: e3b0b0700004        lg      %r11,112(%r11)
    <4>           000000000046636e: 07fe                bcr     15,%r14
    <4>           0000000000466370: a7f40001            brc     15,466372
    <4>          >0000000000466374: a7f4fff6            brc     15,466360
    <4>           0000000000466378: eb7ff0500024        stmg    %r7,%r15,80(%r15)
    <4>           000000000046637e: a7f13e00            tmll    %r15,15872
    <4>           0000000000466382: b90400ef            lgr     %r14,%r15
    <4>           0000000000466386: a7840001            brc     8,466388
    <4>Call Trace:
    <4>([<000201500f85c000>] 0x201500f85c000)
    <4> [<0000000000466556>] vring_interrupt+0x72/0x88
    <4> [<00000000004801a0>] kvm_extint_handler+0x34/0x44
    <4> [<000000000010d22c>] do_extint+0xbc/0xf8
    <4> [<0000000000113f98>] ext_no_vtime+0x16/0x1a
    <4> [<000000000010a182>] cpu_idle+0x216/0x238
    <4>([<000000000010a162>] cpu_idle+0x1f6/0x238)
    <4> [<0000000000568656>] rest_init+0xaa/0xb8
    <4> [<000000000084ee2c>] start_kernel+0x3fc/0x490
    <4> [<0000000000100020>] _stext+0x20/0x80
    <4>
    <4> <0>Kernel panic - not syncing: Fatal exception in interrupt
    <4>

After looking at the code and the dump I think the following scenario
happened: Ifup was running on cpu2 and the interrupt arrived on cpu0.
Now virtnet_open on cpu 2 managed to execute napi_enable and disable_cb
but did not execute rx_schedule. Meanwhile on cpu 0 skb_recv_done was
called by vring_interrupt, executed netif_rx_schedule_prep, which
succeeded and therefore called disable_cb. This triggered the BUG_ON,
as interrupts were already disabled by cpu 2.

I think the proper solution is to make the call to disable_cb depend on
the atomic update of NAPI_STATE_SCHED by using netif_rx_schedule_prep
in the same way as skb_recv_done.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The PHY Lib now uses mutexes instead of spin_locks.  ucc_geth
and gianfar both grab the locks in their mdio_reset functions,
so they need to use mutex_(un)lock instead.  This was not caught
until someone tested it on an SMP system.
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Various registers need to be preserved before resetting the device.
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The driver needs to ack only the phy status bits that it is currently
handling and preserve the other bits for the other handlers. For
example, when reading/writing from the phy, it should not clear the link
change interrupt bit. This will cause a missing link change interrupt.
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch fixes the issue where the transmitter and receiver must be
restarted when applying new changes to certain registers.
Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch converts cpmac to the new Fixed PHY infrastructure, though it
doesn't fix all the problems with that driver. I didn't even bother to
test this patch to compile, because cpmac driver is broken in several ways:

1. This driver won't compile by itself because lack of its header describing
   platform data;
2. It assumes that fixed PHYs should be created by the ethernet driver.
   It is wrong assumption: fixed PHYs creation is platform code authority,
   driver must blindly accept bus_id and phy_id platform data variables
   instead.

Also, it seem that that driver doesn't have actual in-tree users, so
nothing to fix further.

The main purpose of that patch is to get rid of the following Kconfig
warning:

scripts/kconfig/conf -s arch/powerpc/Kconfig
drivers/net/Kconfig:1713:warning: 'select' used by config symbol
'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set,
we have the following warning in build:
  drivers/net/pppol2tp.c: In function 'pppol2tp_init':
  drivers/net/pppol2tp.c:2472: warning: label
'out_unregister_pppox_proto' defined but not used

This patches fixes this warning by adding appropriate #ifdef.
Signed-off-by: NRami Rosen <ramirose@gmail.com>
Acked-by: NJames Chapman <jchapman@katalix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This checks if the DMA address is bigger than what the controller can manage.
It will reallocate the buffers in the GFP_DMA zone in that case.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes two off-by-one errors resulting in array overflows
spotted by the Coverity checker.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: NStefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).

This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.

It is safe to drop these packets, as the association they belong to
is not guaranteed anymore anyway.
This is a security fix in the sense that it prevents information leakage.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: NStefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch makes suspend/resume work with the b43legacy driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume. With an all-zero MAC the device
firmware is not able to ACK any received packets anymore.
Fix this by moving the initializion stuff that must be done on init but
not on resume to the start function.
Also zero out filter_flags to make sure we don't have some flags
from a previous instance for a tiny timeframe until mac80211 reconfigures
them.

This patch by Michael Buesch has been ported to b43legacy.

Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: NStefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix the crash reported below, which seems to happen on bcm4306 rev. 2 devices
only while using PIO:

Oops: 0000 [#1] PREEMPT
Modules linked in: b43(F) rfkill(F) led_class(F) input_polldev(F) arc4 b43legacy mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device ohci1394 ieee1394 ssb pcmcia snd_intel8x0m ehci_hcd uhci_hcd evdev

Pid: 0, comm: swapper Tainted: GF	(2.6.24st3 #2)
EIP: 0060:[<f90f667b>] EFLAGS: 00010002 CPU: 0
EIP is at b43legacy_pio_handle_txstatus+0xbb/0x210 [b43legacy]
EAX: 0000049b EBX: f11f8044 ECX: 00000001 EDX: 00000000
ESI: f1ff8000 EDI: 00000000 EBP: f11f8040 ESP: c04f4ef4
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c04f4000 task=c0488300 task.ti=c04b8000)
Stack: f90f2788 c05009f0 c0500900 000010f7 f1053823 c04f4f24 dfb8e800 00000003
       f1368000 00000007 00000296 f90f1975 00001000 010c0800 01000000 00000007
       f90f6391 f11f8000 00000082 c04f4f4a 00000000 00004fd0 10f70000 8c061000
Call Trace:
 [<f90f2788>] b43legacy_debugfs_log_txstat+0x48/0xb0 [b43legacy]
 [<f90f1975>] b43legacy_handle_hwtxstatus+0x75/0x80 [b43legacy]
 [<f90f6391>] b43legacy_pio_rx+0x201/0x280 [b43legacy]
 [<f90e4fa3>] b43legacy_interrupt_tasklet+0x2e3/0x870 [b43legacy]
 [<c0123567>] tasklet_action+0x27/0x60
 [<c01237b4>] __do_softirq+0x54/0xb0
 [<c010686b>] do_softirq+0x7b/0xe0
 [<c01457c0>] handle_level_irq+0x0/0x110
 [<c01457c0>] handle_level_irq+0x0/0x110
 [<c0123758>] irq_exit+0x38/0x40
 [<c0106953>] do_IRQ+0x83/0xd0
 [<c011812f>] __update_rq_clock+0x4f/0x180
 [<c0104b4f>] common_interrupt+0x23/0x28
 [<c011007b>] wakeup_code+0x7b/0xde
 [<c02b1039>] acpi_processor_idle+0x24a/0x3c9
 [<c01025c7>] cpu_idle+0x47/0x80
 [<c04b9ad5>] start_kernel+0x205/0x290
 [<c04b9360>] unknown_bootoption+0x0/0x1f0
 =======================
Code: 0f 00 00 81 fb ff 00 00 00 0f 87 36 01 00 00 8d 04 db 85 ff 8d 6c c6 40 8d 5d 04 0f 85 ef 00 00 00 fe 4e 0e 0f b7 46 0c 8b 53 04 <8b> 4a 50 29 c8 83 e8 52 66 89 46 0c 8b 54 24 14 80 7a 0b 00 74
EIP: [<f90f667b>] b43legacy_pio_handle_txstatus+0xbb/0x210 [b43legacy] SS:ESP 0068:c04f4ef4
Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: NStefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Generic HDLC now uses random_ether_addr() for generating MAC addresse
for Ethernet-alike interfaces.
Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Removes now unneeded struct hdlc_device_desc
Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Fixes kernel panic in Frame Relay mode
Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Just like our other drivers before we can switch ixgbe to
provide real-time packet/byte counters to the stack easily.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Several counters behave differently on 82598 causing them to display
incorrect values. Adjust the accounting so the reported numbers
make sense and do not double count or represent the wrong item.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

We were not returning CHECKSUM_NONE in a lot of cases which is
wrong. Move common exit points in this function and error code
up before the actual work in this function.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

A gap was left in the FW release/grab code in up/down path. Fix
it by making the release/grab code a function and calling it in
appropriate locations.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The i82598 can support various media types but this ethtool
code only was coded for fiber just yet.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This ports Herbert Xu's "maybe_stop_tx" code and removes the tx_lock
which is not needed.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

After testing we confirmed that the irq_sem can safely be
removed from ixgbe.

Add strict state checking code to various ethtool parts to
properly protect against races between various driver reset
paths.
Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Changes in other networking paths uncovered a bug in the xircom_cb
driver which made the kernel spew lots of the following error messages:

  BUG eth1 code -5 qlen 0

It turned out that the driver returned -EIO when there was no
descriptor available for sending packets. It should return
NETDEV_TX_BUSY instead. This was discussed on the netdev list before,
see http://thread.gmane.org/gmane.linux.network/84603 .
Signed-off-by: NErik Mouw <mouw@nl.linux.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Add a check for the pci_register_driver() return value.  Removed unused
variable pad_allocated.

The aim of this patch is to remove the following warning messages:
drivers/net/tlan.c: In function 'tlan_probe':
drivers/net/tlan.c:486: warning: ignoring return value of 'pci_register_driver', declared with attribute warn_unused_result
Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The Marvell Orion system on chips have an integrated mv643xx MAC.  On these
little endian ARM devices mv643xx will oops when checksum offload is
enabled.  Swapping the byte order of the protocol and checksum solves this
problem.
Signed-off-by: NByron Bradley <byron.bbradley@gmail.com>
Cc: Dale Farnsworth <dale@farnsworth.org>
Cc: Manish Lachwani <mlachwani@mvista.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The Yukon FE chip has a ram buffer therefore it needs the alignment
restriction and hang check workarounds.

Therefore:
  * Autodetect the prescence/absence of ram buffer
  * Rename the flag value to reflect this
  * Use it consistently (ie don't reread register)
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>