Fix up IRDA drivers that return an errno value to qdisc_restart(), causing
qdisc_restart() to print a warning an requeue/retransmit the skb.

- donauboe: intention appears to be to have the skb retransmitted without
            error message
- irda-usb: intention is to drop silently according to comment
- kingsub-sir: skb is freed: use after free
- ks959-sir: skb is freed: use after free
- ksdazzle-sir: skb is freed: use after free
- mcs7880: skb is freed: use after free

All but donauboe compile tested.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix up drivers that return an errno value to qdisc_restart(), causing
qdisc_restart() to print a warning and requeue/retransmit the skb.

- xpnet: memory allocation error, intention is to drop
- ethoc: oversized packet, packet must be dropped
- ibmlana: skb freed: use after free
- rrunner: skb freed: use after free
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes FDB entry check for ATM LANE bridge integration.
There's no point in holding a FDB entry around SKB building.

br_fdb_get()/br_fdb_put() pair are changed into single br_fdb_test_addr()
hook that checks if the addr has FDB entry pointing to other port
to the one the request arrived on.

FDB entry refcounting is removed as it's not used anywhere else.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit b00055aa " [NET] core: add
RFC2863 operstate" defined new interface flag values.  Its
documentation specified that these flags could be accessed from user
space via SIOCGIFFLAGS.  However, this does not work because the new
flags do not fit in that ioctl's argument width.

Change the documentation to match the code's behavior.  Also change
the source to explicitly show the truncation.  This _should_ have no
effect on executable code, and did not with gcc 4.2.4 generating x86
code.

A new ioctl could be defined to return all interface flags to user
space.  However, since this has been broken for three years with no
one complaining, there doesn't seem much need.  They are still
accessible via netlink.
Reported-by: N"Fredrik Arnerup" <fredrik.arnerup@edgeware.tv>
Signed-off-by: NJohn Dykstra <john.dykstra1@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We need to enforce the IP alignment on the non-mergeable RX path just
like the other RX path.  Not doing so results in misaligned IP
headers.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some drivers incorrectly use ntohs() instead of htons()

A cleanup as htons() returns same result than ntohs(),
but better to use the proper one.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix build error introduced by commit bb70dfa5 (netfilter: xtables:
consolidate comefrom debug cast access):

net/ipv4/netfilter/ip_tables.c: In function 'ipt_do_table':
net/ipv4/netfilter/ip_tables.c:421: error: 'comefrom' undeclared (first use in this function)
net/ipv4/netfilter/ip_tables.c:421: error: (Each undeclared identifier is reported only once
net/ipv4/netfilter/ip_tables.c:421: error: for each function it appears in.)
Signed-off-by: NPatrick McHardy <kaber@trash.net>

SH4's BUG() seems to confuse the compiler as it is considered to
return; thus, some functions would trigger usage of uninitialized
variables or non-void functions returning void.

Work around by initializing/returning.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Caused by an API update. The return value can be safely ignored, as
there is notthing we can do with it.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Remove unused stuff.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>

This fix triggering the WARN_ON_ONCE(in_irq() || irqs_disabled()); in
local_bh_enable().

Here is no need to grab this lock, this was wrong at all and may
cause a deadlock and access to freed memory, since on a TEI remove
the current listelement can be deleted under us. So this is clearly
a case for list_for_each_entry_safe.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>

The check for overindexing of dev->mdm.info[] has an off-by-one.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NKarsten Keil <keil@b1-systems.de>

If we get no interrupts for after 3 resets we need to unregister
the interrupt function, which is already done outside the loop.
Signed-off-by: NAndreas Mohr <andi@lisas.de>
Signed-off-by: NKarsten Keil <keil@b1-systems.de>

Remove code rewriting a buffer by itself.
This fix bug 12970 on bugzilla.kernel.org.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>

Replace wrong code with correct DMA API functions.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>

Replace the last occurence of tcp_lock by the per-conntrack lock.
Signed-off-by: NPatrick McHardy <kaber@trash.net>

Some users still load bond module multiple times to create bonding
devices.  This accidentally was broken by a later patch about
the time sysfs was fixed.  According to Jay, it was broken
by:
   commit b8a9787e
   Author: Jay Vosburgh <fubar@us.ibm.com>
   Date:   Fri Jun 13 18:12:04 2008 -0700

     bonding: Allow setting max_bonds to zero

Note: sysfs and procfs still produce WARN() messages when this is done
so the sysfs method is the recommended API.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current code errors out the INCOMPLETE neigh entry skb queue only from
the timer if maximum probes have been attempted and there has been no reply.
This also causes the transtion to FAILED state.

However, the neigh entry can be also updated via Netlink to inform that the
address is unavailable.  Currently, neigh_update() just stops the timers and
leaves the pending skb's unreleased. This results that the clean up code in
the timer callback is never called, preventing also proper garbage collection.

This fixes neigh_update() to process the pending skb queue immediately if
INCOMPLETE -> FAILED state transtion occurs due to a Netlink request.
Signed-off-by: NTimo Teras <timo.teras@iki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the i2400m device resets, the driver code will force some
functions to return a -ERESTARTSYS error code, which can is used by
the caller to determine which recovery actions to take.

However, in certain situations the only thing that can be done is to
bubble up said error code to user space, for handling.

However, -ERESTARSYS was a poor choice, as it is supposed to be used
by the kernel only.

As such, replace -ERESTARTSYS with -EL3RST; as well, in
i2400m_msg_to_dev(), when the device is in boot mode (following a
recent reset), return -EL3RST instead of -ENODEV (meaning the device
is in bootrom mode after a reset, not that the device was
disconnected, and thus, normal commands cannot be executed).
Signed-off-by: NCindy H Kao <cindy.h.kao@intel.com>

When a device reset happens during firmware load [in
i2400m_dev_bootstrap()], __i2400m_dev_start() will retry a number of
times. However, for those retries to be able to accomplish anything,
the device's bootrom has to be reinitialized.

Thus, on the retry path, pass the I2400M_MAC_REINIT to the firmware
load code.
Signed-off-by: NCindy H Kao <cindy.h.kao@intel.com>

The current SDIO code was working in polling mode for boot-mode
(firmware load) mode. This was causing issues on some hardware.

Moved all the RX code to use a unified IRQ handler that based on the
type of data the device is sending can discriminate and decide which
is the right destination.

As well, all the reads from the device are made to be at least the
block size (256); the driver will ignore the rest when not needed.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

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: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Add a poke table for the SDIO device (as it is different than USB).
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@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: NDirk 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: NInaky 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: NInaky 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: NInaky 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: NInaky 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: NInaky 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: NInaky 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: NInaky 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: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>

Changing debug level of print out to support validation engineers
getting the messages they need.
Signed-off-by: N  <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: NInaky 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: NInaky 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: NInaky Perez-Gonzalez <inaky@linux.intel.com>