Slip and a few other drivers use the same ioctl numbers on
tty devices that are normally meant for sockets. This causes
problems with our compat_ioctl handling that tries to convert
the data structures in a different format.

Fortunately, these five drivers all use 32 bit compatible
data structures in the ioctl numbers, so we can just add
a trivial compat_ioctl conversion function to each of them.

SIOCSIFENCAP and SIOCGIFENCAP do not need to live in
fs/compat_ioctl.c after this any more, and they are not
used on any sockets.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The tun driver is the only code in the kernel that operates
on a character device with struct ifreq. Change the driver
to handle the conversion itself so we can contain the
remaining ifreq handling in the socket layer.

This also fixes a bug in the handling of invalid ioctl
numbers on an unbound tun device. The driver treats this
as a TUNSETIFF in native mode, but there is no way for
the generic compat_ioctl() function to emulate this
behaviour. Possibly the driver was only doing this
accidentally anyway, but if any code relies on this
misfeature, it now also works in compat mode.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The generic __sock_create function has a kern argument which allows the
security system to make decisions based on if a socket is being created by
the kernel or by userspace.  This patch passes that flag to the
net_proto_family specific create function, so it can do the same thing.
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In BCM8481 when link speed goes from 1G to 10M, driver received timeout
since the MAC clock hasn't synced yet with the new speed, so it is required
first to program the MAC with the new speed, and only then configure other
parameters
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for new phy type BCM84823 (Dual copper-port phy)
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Modify BCM8706 link initialization sequence so that first it link up
between Serdes and BCM8706, and only then between BCM8706 to network
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When parallel detect is used, flow-control is set to the
req_fc_auto_adv instead of none.

Motive: when 577xx is FC configuration is set to AUTO, while LP speed
is set to FORCE mode and FC to force RX/TX, link would come up using
parallel detect, and the FC will be set to NONE since FC capabilities
were not negotiated, although the LP is setting FC to force RX/TX.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- Advertise 1G KX4 in CL73 when 1G speed capability is enabled
- Add flow-control negotiation over CL73
- External loopback test on Serdes should be done in FORCE mode, since in
CL73 it is unable to link up with the same core using AUTONEG
- Fix bnx2x_set_led function to support CL73 link leds
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Enable Parallel-Detect for 10G and 1G only if the relevant speed
capability is enabled
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit

	3d1285be (move virtnet_remove to .devexit.text)

introduced the first reference to __devexit in struct virtio_driver
virtio_net which upset modpost ("Section mismatch in reference from the
variable virtio_net to the function .devexit.text:virtnet_remove()").

Fix this by renaming virtio_net to virtio_net_driver.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Blame-taken-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add suspend/resume capability to TI DaVinci EMAC driver.
Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use spin_trylock_irqsave instead of open-coded
local_irq_save+spin_trylock.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

emac_irq is declared as:

static irqreturn_t emac_irq(int irq, void *dev_id)
{
       struct net_device *ndev = (struct net_device *)dev_id;
       struct emac_priv *priv = netdev_priv(ndev);
    ... 

	Clearly emac_irq() needs "struct net_device *" as "void *dev_id", so correct this.
Signed-off-by: NTonyliu <Bo.Liu@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NTorgny Johansson <torgny.johansson@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

drivers/net/bnx2.c: In function ‘bnx2_enable_forced_2g5’:
drivers/net/bnx2.c:1447: warning: ‘bmcr’ may be used uninitialized in this function
drivers/net/bnx2.c: In function ‘bnx2_disable_forced_2g5’:
drivers/net/bnx2.c:1482: warning: ‘bmcr’ may be used uninitialized in this function

One fix would be to have an initial value, but a plain return might be better.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the kernel api already has the macro "min",
just use it instead of declaring another one.
Signed-off-by: NThiago Farina <tfransosi@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

`ulp_type' is signed, make sure it is not negative
when we read the array element.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't access netdev->stats in IO path.  Save them in tx_ring/rx_rings
and add them up when get_stats API is called.
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These sub-commands are issued by another (FCoE) function requesting
an operation on a shared resource.
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix inverted setting of 'retries'; when we are in the probe() path, we
should retry to enable the function only once; otherwise until it
times out.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The SDIO specific debugfs dentry was being misnamed "i2400m-usb"
instead of "i2400m-sdio".
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The function was always setting the return value to the amount of
bytes transferred, overwriting the error code in error paths.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

When the device stalls, clear it and retry; if it keeps failing too
often, reset the device.

This specially happens when running on virtual machines; the real
hardware doesn't seem to trip on stalls too much, except for a few
reports in the mailing list (still to be confirmed this is the cause,
although it seems likely.

NOTE: it is not clear if the URB has to be resubmitted fully or start
only at the offset of the first transaction sent. Can't find
documentation to clarify one end or the other.

Tests that just resubmit the whole URB seemed to work in my
environment.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The iwmc3200 has a quirk where retrying SDIO enable during the probe()
path causes bad interactions with the TOP function controller that
causes a reset storm. The workaround is simply not to retry an SDIO
enable in said path (and still do in the reset / reinitialization
paths).

The driver does so by checking i2400ms->debugfs_dentry to see if it
has been initialized; if not, it is in the probe() path. Document said
fact in i2400ms->debugfs_entry.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Different paths of the i2400m SDIO driver need to take care of a few
SKU-specific quirks. For the ones that are common to to all the
iwmc3200 based devices, introduce i2400ms->iwmc3200 [set in
i2400ms_probe()], so it doesn't have to check against the list of
iwmc3200 SKU IDs on each quirk site.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The USB code was incorrectly specifiying timeouts to be in jiffies vs
msecs. On top of that, lower it to 200ms, as 1s is really too long
(doesn't allow the watchdog to trip a reset if the device timesout too
often).
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The i2400m, when conected, will negotiate with the WiMAX basestation
to put the link in IDLE mode when it is not being used. Upon RX/TX
traffic, the link has to be restablished and that might require some
crypto handshakes and maybe a DHCP renew.

This process might take up to 20 (!) seconds and in some cases we were
seeing network watchdog warnings that weren't needed.

So the network watchdog timeout is updated to be slightly above that
20s threshold. As well, the driver itself will double check if the
device is stuck in IDLE mode -- if that happens, the device will be
reset (in this case the queue is also woken up to remove bogus--once
the device is reset--warnings).
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Currently the i2400m driver was resetting by just calling
i2400m->bus_reset(). However, this was missing stopping the TX queue
and downing the carrier. This was causing, for the corner case of the
driver reseting a device that refuses to go out of idle mode, that a
few packets would be queued and more than one reset would go through,
making the recovery a wee bit messy.

To avoid introducing the same cleanup in all the bus-specific driver,
introduced a i2400m_reset() function that takes care of house cleaning
and then calling the bus-level reset implementation.

The bulk of the changes in all files are just to rename the call from
i2400m->bus_reset() to i2400m_reset().
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Some versions of the user space Intel WiMAX daemon need to have full
control over the device initialization sequence. By setting the module
option i2400.passive_mode to 1, the driver defers all device
configuration and initialization to user space.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

- TC35815_DMA_SYNC_ONDEMAND is always enabled.
- WORKAROUND_LOSTCAR is always enabled.
- WORKAROUND_100HALF_PROMISC is always enabled.
- GATHER_TXINT is always enabled.
- TC35815_USE_PACKEDBUFFER is always disabled.
- NO_CHECK_CARRIER is always disabled.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch provides basic hash rules programming via the ethtool
interface.
Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch introduces multiple group support for etsec2.0
devices.

Multiple group support is provided by mapping the set of enabled
queues to different groups and then programming the per group
regsiters imask, ievent, rstat, tstat.

The queues corresponding to a group are indicated by programming
isrg (interrupt steering) registers.
Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds support for etsec2.0 regsiters
Signed-off-by: NSandeep Gopalpet <Sandeep.Kumar@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>