On certain SOCs, the EMAC controller is interfaced with a wrapper logic
for handling interrupts. This  patch implements a platform
specific hook to cater to platforms that require custom interrupt
handling logic
Signed-off-by: NSriramakrishnan <srk@ti.com>
Acked-by: NChaithrika U S <chaithrika@ti.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The davinci EMAC peripheral is also available on other TI
platforms -notably TI AM3517 SoC. This patch modifies the
config option and the platform structure header files so that
the driver can be reused on non-davinci platforms as well.
Signed-off-by: NSriramakrishnan <srk@ti.com>
Acked-by: NChaithrika U S <chaithrika@ti.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

I have seen RX stalls on a machine that experienced a suspected
OOM.  After the stall, the RX buffer is empty on the guest side
and there are exactly 16 entries available on the host side.  As
the number of entries is less than that required by a maximal
skb, the host cannot proceed.

The guest did not have a refill job scheduled.

My diagnosis is that an OOM had occured, with the delayed refill
job scheduled.  The job was able to allocate at least one skb, but
not enough to overcome the minimum required by the host to proceed.

As the refill job would only reschedule itself if it failed completely
to allocate any skbs, this would lead to an RX stall.

The following patch removes this stall possibility by always
rescheduling the refill job until the ring is totally refilled.

Testing has shown that the RX stall no longer occurs whereas
previously it would occur within a day.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The low-level MCDI code always uses 32-bit MMIO operations, and
callers must pad input and output buffers to multiples of 4 bytes.
The MCDI NVRAM functions are not doing this.  Also, their buffers are
declared as variable-length arrays with no explicit maximum length.

Switch to a fixed buffer size based on the chunk size used by the
MTD driver (which is a multiple of 4).
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Due to a hardware bug in the SFC9000 family, the firmware must
transfer raw GMAC statistics to host memory before aggregating them
into the cooked (speed-independent) MAC statistics.  Extend the stats
buffer to support this.

The length of the buffer is explicit in the MAC_STATS command, so this
change is backward-compatible on both sides.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently qlge tries to release regions even if they were not allocated.
This causes messages like the following in the kernel log

Trying to free nonexistent resource <00000000006af400-00000000006af4ff>
Trying to free nonexistent resource <00003c04ff9f4000-00003c04ff9f7fff>
Trying to free nonexistent resource <00003c04ffc00000-00003c04ffcfffff>

This patch fixes the goto logic in order to not release the resources
if they were not allocated.
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Obviously, this register had some other impact that is causing
the regression.  Either it is masking some other access or needs
to be reset in some path.

Either, way it is best to just revert the change for 2.6.33

This reverts commit 166a0fd4.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Y2_HW_WOL_ON/Y2_HW_WOL_OFF should be set and cleared per chip,
not per port.  On dual port cards, Y2_HW_WOL_ON should be
enabled if either sky2 port has WOL enabled.

Found while reviewing code for a WOL regression, though this is
probably not the cause of the regression.
Signed-off-by: NMike McCormack <mikem@ring3k.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Found this problem when testing IPv6 from a KVM guest to a remote
host via e1000e device on the host.
The following patch fixes the check for IPv6 GSO packet in Intel
ethernet drivers to use skb_is_gso_v6(). SKB_GSO_DODGY is also set
when packets are forwarded from a guest.
Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After removing the skb_dma_map/unmap calls the exception handling in
igb_tx_map_adv is not correct.  The issue is that the count value was not
being correctly handled so as a result we were not rewinding the ring as
back as we should have been.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When testing the "e1000: enhance frame fragment detection" (and e1000e)
patches we found some bugs with reducing the MTU size.  The 1024 byte
descriptor used with the 1000 mtu test also (re) introduced the
(originally) reported bug, and causes us to need the e1000_clean_tx_irq
"enhance frame fragment detection" fix.

So what has occured here is that 2.6.32 is only vulnerable for mtu <
1500 due to the jumbo specific routines in both e1000 and e1000e.
So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
is not vulnerable to the original issue reported.  It has been pointed
out that this vulnerability needs to be patched in older kernels that
don't have the e1000 jumbo routine.  Without the jumbo routines, we
need the "enhance frame fragment detection" fix the e1000, old
e1000e is only vulnerable for < 1500 mtu, and needs a similar
fix.  We split the patches up to provide easy backport paths.

There is only a slight bit of extra code when this fix and the
original "enhance frame fragment detection" fixes are applied, so
please apply both, even though it is a bit of overkill.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

fmvj18x_cs, serial_cs:
 add new id
 Panasonic lan & modem card (model name:AL-VML101)
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Only the first two fields of mcc wrb - embedded, payload_len
need to be cpu_to_le32() swapped while issuing a cmd to the hw.
The fields tag0, tag1 are opaque and returned back to cpu as is...
Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Please add support for Microsoft MN-120 PCMCIA network card. It's an
old card, I know, but adding support is very easy. You just need to
get tulip_core.c to recognise its vendor/device ID.

Patch for kernel 2.6.32.4 (and many previous) attached.

 .....Ron Murray
Signed-off-by: NRon Murray <rjmx@rjmx.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Pages are posted to the rxq in such a way that more than one frag
can share the page. The last frag that uses the page unmaps the
page.  In the case when a page is not fully used (due to lack of space in rxq)
the last frag that uses the page is not being set as a "last_page_user";
instead, the next frag in the rxq is incorrectly being set.

The fix has also been tested on ppc64 with 64k pages...
Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Intel WiMax Wireless Link 6050 can show under more than one USB
ID. Add support for all, introducing a generic flag (i2400mu->i6050)
that denotes a 6x50 based device.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Originally patched by Neil Horman <nhorman@tuxdriver.com>

e1000e could with a jumbo frame enabled interface, and packet split disabled,
receive a packet that would overflow a single rx buffer.  While in practice
very hard to craft a packet that could abuse this, it is possible.

this is related to CVE-2009-4538
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Originally From: Neil Horman <nhorman@tuxdriver.com>
Modified by: Jesse Brandeburg <jesse.brandeburg@intel.com>

Hey all-
	A security discussion was recently given:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
And a patch that I submitted awhile back was brought up.  Apparently some of
their testing revealed that they were able to force a buffer fragment in e1000
in which the trailing fragment was greater than 4 bytes.  As a result the
fragment check I introduced failed to detect the fragement and a partial
invalid frame was passed up into the network stack.  I've written this patch
to correct it.  I'm in the process of testing it now, but it makes good
logical sense to me.  Effectively it maintains a per-adapter state variable
which detects a non-EOP frame, and discards it and subsequent non-EOP frames
leading up to _and_ _including_ the next positive-EOP frame (as it is by
definition the last fragment).  This should prevent any and all partial frames
from entering the network stack from e1000.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The variable count and i are unsigned so the (<|>=)0 tests do not work.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix check to verify if a register bit is set. We have not hit this bug because
wait_for_cmd_complete() is always called with S2IO_BIT_RESET. 
Reported by Roel Kluin <roel.kluin@gmail.com>.
Signed-off-by: NRam Vepa <ram.vepa@neterion.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver tweaks VR_CTL, so pull in the header for the bit defines.
Also switch to the new define name as the old one has gone away.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Checking the PHY XS MMD here is unnecessary and can give false negatives.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 7583605b ("ucc_geth: Fix empty
TX queue processing") fixed empty TX queue mishandling, but didn't
account another corner case: when TX queue becomes full.

Without this patch the driver will stop transmiting when TX queue
becomes full since 'bd == ugeth->txBd[txQ]' actually checks for
two things: queue empty or full.

Let's better check for NULL skb, which unambiguously signals an empty
queue.
Signed-off-by: NJiajun Wu <b06378@freescale.com>
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: Stable <stable@vger.kernel.org> [2.6.32]
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 541cd3ee ("phylib: Fix deadlock
on resume") caused TI DaVinci EMAC ethernet driver to oops upon resume:

 PM: resume of devices complete after 237.098 msecs
 Restarting tasks ... done.
 kernel BUG at kernel/workqueue.c:354!
 Unable to handle kernel NULL pointer dereference at virtual address 00000000
 [...]
 Backtrace:
 [<c002c598>] (__bug+0x0/0x2c) from [<c0052a54>] (queue_delayed_work_on+0x74/0xf8)
 [<c00529e0>] (queue_delayed_work_on+0x0/0xf8) from [<c0052b30>] (queue_delayed_work+0x2c/0x30)

The oops pops up because TI DaVinci EMAC driver detaches PHY on
suspend and attaches it back on resume. Attaching makes phylib call
phy_start_machine() that initializes a workqueue. On the other hand,
PHY's resume routine will call phy_start_machine() again, and that
will cause the oops since we just destroyed the already scheduled
workqueue.

This patch fixes the issue by moving workqueue initialization to
phy_device_create().

p.s. We don't see this oops with ucc_geth and gianfar drivers because
they perform a fine-grained suspend, i.e. they just stop the PHYs
without detaching.
Reported-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Yasuhiro ABE <yadiary@gmail.com> reported success in sourceforge zd1211-dev list.
The device is a NEC Aterm WL54GU usb wireless stick.

The brand and retail product name
    NEC, Aterm PA-WL54GU
The USB ID's (duh)
    ID 0409:0248
The chip ID string
    zd1211rw 1-1:1.0: zd1211b chip 0409:0248 v4810 high 00-1b-8b AL2230S_RF pa0 g--N-
The FCC ID
    unknown
Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: NYasuhiro ABE <yadiary@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A long time ago, a user reported several crashes due to
data corruptions which are likely the result of a
not-100%-supported, or faulty? PCI bridge.
( http://patchwork.kernel.org/patch/53004/ )

This patch fixes entry #1.
"1.  p54p_check_rx_ring - skb_over_panic: Under a ping flood
or just left running for a bit would panic with a skb_over_panic."
As described in the mail: The invalid frame length causes
skb_put to bailout and trigger a crash.

Note:
Simply dropping the frame is problematic, because if its content
contains a tx feedback we would lose some portion of the device
memory space.... And the driver/mac80211 should handle all other
invalid data.
Reported-by: NQuintin Pitts <geek4linux@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Similar to 6000 and 1000 series, RTS/CTS is the recommended protection
mechanism for 5000 series in HT mode based on the HW design.

Using RTS/CTS will better protect the inner exchange from interference,
especially in highly-congested environment, it also prevent uCode encounter
TX FIFO underrun and other HT mode related performance issues.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Without this header, we can trigger a UMAC crash with debug enabled UMACs.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch updates the copyright notice for 2010 and updates the version
number to 3.106.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The B0 revision of the 5717 will not get enough testing by the time
2.6.33 ships.  Since the kernel is already at RC3, serdes support
will require too many patches to fix.  For these reasons, this patch
disables 5717 serdes support and will refuse to attach to all 5717
devices that are later than an A0 revision.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The serdes status bit does not work as intended for the 5717 A0.
This patch implements an alternative detection scheme that will only be
valid for A0 revisions.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are some tg3 devices that require the driver to post new rx
buffers in smaller increments.  Commit
4361935a, "tg3: Consider
rx_std_prod_idx a hw mailbox" changed how the driver tracks the rx
producer ring updates, but it does not make any special considerations
for the above-mentioned devices.  For those devices, it is possible for
the driver to hit the special case path, which updates the hardware
mailbox register but skips updating the shadow software mailbox member.
If the special case path represents the final mailbox update for this
ISR iteration, the hardware and software mailbox values will be out of
sync.  Ultimately, this will cause the driver to use a stale mailbox
value on the next iteration, which will appear to the hardware as a
large rx buffer update.  Bad things ensue.

The fix is to update the software shadow mailbox member when the special
case path is taken.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 87668d35, titled "tg3: Don't
touch RCB nic addresses", tried to avoid assigning the nic address of
the standard producer ring.  Unfortunately, the default nic address is
not correct for the 5787, the 5755M, or the 57765.  This patch
reenables the old behavior and opts out of the assignment only
for the 5717.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Tested-by: NChow Loong Jin <hyperair@ubuntu.com>
Tested-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MDIO self-test should not be run on boards without an MDIO PHY,
such as SFN5122F-R3 and later revisions.  It should also not try to
address a specific MMD in an MDIO clause 22 PHY.  Check the
mode_support field to decide which mode to use, if any.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the interface is down and we are using polled mode for MCDI
operations, we busy-wait for completion for approximately 1 jiffy
using udelay() and then back off to schedule().  But the completion
will not wake the task, since we are using polled mode!  We must use
schedule_timeout_uninterruptible() instead.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes a delay in hardware after every received packet allowing
more time for transmitted packets to go out in between received packets in
half duplex.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A previous 82577 workaround that set the MDIO access speed to slow mode for
every PHY register read/write when the cable is unplugged should instead
set the access mode to always be slow before any PHY register access.
Since the mode bit gets cleared when the PHY is reset, set the mode after
every PHY reset.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch resolves issues seen when running netconsole and rebooting via
reboot -f.  The issue was due to the fact that we were attempting to
perform interrupt actions when the q_vectors and rings had already been
freed via the ixgbe_shutdown routines.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Acked-by: NMallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>