These are only used by btcoex.c on one routine, so stuff them
into that file.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After some necessary cleanups we now move ath9k_hw_btcoex_set_weight()
to where it belongs.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The second argument is always the hardware bt coex struct, so
remove it, and rename the function on the path with a ath9k_ prefix.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

btcoex_scheme is already part of a btcoex struct, its implied
this is btcoex related.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The bt_stomp_type defines the bt coex weight, it has a one-to-one
mapping. In the future we may want to just use the weight directly.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whether or not bluetooth coex has been enabled is a hardware
state and only the hardware helpers will be able to set this.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

One for 2-wire and another for 3-wire.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Keep on btcoex.c only hardware access helpers, move the
driver core specific code to main.c. To accomplish
this we had to split ath_init_btcoex_info() into two parts,
the driver core part -- ath_init_btcoex_timer() and the hw
specific part -- ath9k_hw_init_btcoex_hw_info(). This
highlights how ath_gen_timer is part of the driver core, not
hw related, so stuff that into ath_btcoex struct.

The ath9k_hw_btcoex_init() code is now put inline on
ath_init_softc() through a switch to it easier to follow,
since we did that we can now call ath_tx_get_qnum() from
the main.c instead of btcoex.c
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a helper for 2-wire and another for 3-wire.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since we now access it via the ath_hw declare the ath_hw pointer
at the header of some routines and se it. ath9k.h no longer needs to
access btcoex.h and to adjust for this move ath_btcoex_set_weight()
into btcoex.h and instead give main.c a helper for setting initial
values upon drv_start()
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is some bluetooth coexistance data which is driver
specific, stuff that into its own structure.

Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

DPRINTF() is used in hw specific related code, as such
ensure we don't rely on the private driver core ath_softc
struct when calling it. Drivers can then implement their
own DPRINTF() as they see fit.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch exports the link-speed (in Mbps) and duplex of an interface
via sysfs.  This eliminates the need to use ethtool just to check the
link-speed.  Not requiring 'ethtool' and not relying on the SIOCETHTOOL
ioctl should be helpful in an embedded environment where space is at a
premium as well.

NOTE: This patch also intentionally allows non-root users to check the link
speed and duplex -- something not possible with ethtool.

Here's some sample output:

# cat /sys/class/net/eth0/speed
100
# cat /sys/class/net/eth0/duplex
half
# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised auto-negotiation: No
        Speed: 100Mb/s
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Instead of having to modify every non-mac80211 for device type assignment,
do this inside the netdev notifier callback of cfg80211. So all drivers
that integrate with cfg80211 will export a proper device type.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For various purposes including a wireless extensions
bugfix, we need to hook into the netdev creation before
before netdev_register_kobject(). This will also ease
doing the dev type assignment that Marcel was working
on for cfg80211 drivers w/o touching them all.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For usbnet devices with FLAG_WLAN and FLAG_WWAN set the proper device
type so that uevent contains the correct value. This then allows an easy
identification of the actual underlying technology of the Ethernet device.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add support for usbnet based devices like CDC-Ether to indicate that they
are actually mobile broadband devices. In that case use wwan%d as default
interface name.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We currently dirty a cache line to update tunnel device stats
(tx_packets/tx_bytes). We better use the txq->tx_bytes/tx_packets
counters that already are present in cpu cache, in the cache
line shared with txq->_xmit_lock

This patch extends IPTUNNEL_XMIT() macro to use txq pointer
provided by the caller.

Also &tunnel->dev->stats can be replaced by &dev->stats
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The FIB algorithim for IPV4 is set at compile time, but kernel goes through
the overhead of function call indirection at runtime. Save some
cycles by turning the indirect calls to direct calls to either
hash or trie code.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add Ancilliary data to better represent loss information

I've had a few requests recently to provide more detail regarding frame loss
during an AF_PACKET packet capture session.  Specifically the requestors want to
see where in a packet sequence frames were lost, i.e. they want to see that 40
frames were lost between frames 302 and 303 in a packet capture file.  In order
to do this we need:

1) The kernel to export this data to user space
2) The applications to make use of it

This patch addresses item (1).  It does this by doing the following:

A) Anytime we drop a frame for which we would increment po->stats.tp_drops, we
also no increment a stats called po->stats.tp_gap.

B) Every time we successfully enqueue a frame to sk_receive_queue, we record the
value of po->stats.tp_gap in skb->mark.  skb->cb would nominally be the place to
record this, but since all the space there is used up, we're overloading
skb->mark.  Its safe to do since any enqueued packet is guaranteed to be
unshared at this point, and skb->mark isn't used for anything else in the rx
path to the application.  After we record tp_gap in the skb, we zero
po->stats.tp_gap.  This allows us to keep a counter of the number of frames lost
between any two enqueued packets

C) When the application goes to dequeue a frame from the packet socket, we look
at skb->mark for that frame.  If it is non-zero, we add a cmsg chunk to the
msghdr of level SOL_PACKET and type PACKET_GAPDATA.  Its a 32 bit integer that
represents the number of frames lost between this packet and the last previous
frame received.

Note there is a chance that if there is frame loss after a receive, and then the
socket is closed, some gap data might be lost.  This is covered by the use of
the PACKET_AUXDATA socket option, which gives total loss data.  With a bit of
math, the final gap can be determined that way.

I've tested this patch myself, and it works well.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>

 include/linux/if_packet.h |    2 ++
 net/packet/af_packet.c    |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use BIT for macro definitions wherever possible, remove
unused and redundant macros.
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We can avoid two atomic ops on skb->users if packet is not going to be
sent to the device (because hardware txqueue is full)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We can make icmp messages tx completion callback a litle bit faster.

Setting SOCK_USE_WRITE_QUEUE sk flag tells sock_wfree() to
not call sk_write_space() on a socket we know no thread is posssibly
waiting for write space. (on per cpu kernel internal icmp sockets only)

This avoids the sock_def_write_space() call and
read_lock(&sk->sk_callback_lock)/read_unlock(&sk->sk_callback_lock) calls
as well.

We avoid three atomic ops.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The in-tree implementations have all been converted to
get_sset_count().
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These string query operations were supposed to be replaced by the
generic get_sset_count() starting in 2007.  Convert the remaining
implementations.

Also remove calls to these operations to initialise drvinfo->n_stats.
The ethtool core code already does that.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Acked-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This string query operation was supposed to be replaced by the
generic get_sset_count() starting in 2007.  Convert tehuti's
implementation.

Also remove the dummy self-test name which was not used since tehuti
does not advertise any self-tests.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This string query operation was supposed to be replaced by the
generic get_sset_count() starting in 2007.  Convert qeth's
implementation.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I'm skipping -rc2 because the -rc1 Makefile mistakenly said -rc2, so in
order to avoid confusion, I'm jumping from -rc1 to -rc3.  That way, when
'uname' (or an oops report) says 2.6.32-rc2, there's no confusion about
whether people perhaps meant -rc1 or -rc2.

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'acpi-pad' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  acpi_pad: build only on X86
  ACPI: create Processor Aggregator Device driver

Fixup trivial conflicts in MAINTAINERS file.

* 'sfi-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-sfi-2.6:
  SFI: remove __init from sfi_verify_table
  SFI: fix section mismatch warnings in sfi_core.c

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  ACPI: EC: Don't parse DSDT for EC early init on Compal
  ACPI: EC: Rewrite DMI checks
  ACPI: dock: fix "sibiling" typo
  ACPI: kill overly verbose "throttling states" log messages
  ACPI: Fix bound checks for copy_from_user in the acpi /proc code
  ACPI: fix bus scanning memory leaks
  ACPI: EC: Restart command even if no interrupts from EC
  sony-laptop: Don't unregister the SPIC driver if it wasn't registered
  sony-laptop: remove _INI call at init time
  sony-laptop: SPIC unset IRQF_SHARED, set IRQF_DISABLED
  sony-laptop: remove device_ctrl and the SPIC mini drivers

* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  macintosh: Don't assume i2c device probing always succeeds
  i2c: Hide probe errors caused by ACPI resource conflicts
  i2c: Minor documentation update
  mfd: AB3100 drop unused module parameters
  Staging: IIO: tsl2561: Drop unused module parameters
  leds: leds-pca9532 - Drop unused module parameters
  ltc4215/ltc4245: Discard obsolete detect methods
  ds2482: Discard obsolete detect method
  max6875: Discard obsolete detect method
  i2c: Move misc devices documentation

If i2c device probing fails, then there is no driver to dereference
after calling i2c_new_device(). Stop assuming that probing will always
succeed, to avoid NULL pointer dereferences. We have an easier access
to the driver anyway.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NTim Shepard <shep@alum.mit.edu>
Cc: Colin Leroy <colin@colino.net>

When an ACPI resource conflict is detected, error messages are already
printed by ACPI. There's no point in causing the driver core to print
more error messages, so return one of the error codes for which no
message is printed.

This fixes bug #14293:
http://bugzilla.kernel.org/show_bug.cgi?id=14293Signed-off-by: NJean Delvare <khali@linux-fr.org>

The sysfs path to i2c adapters has changed recently, update the
documentation to reflect that change.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The I2C_CLIENT_INSMOD_1 macro is only useful for i2c drivers which
implement device detection. The ab3100 driver doesn't, so there is no
point in calling it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>

The I2C_CLIENT_INSMOD macro is only useful for i2c drivers which
implement device detection. The tsl2561 driver doesn't, so there
is no point in calling it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Jonathan Cameron <jic23@cam.ac.uk>