Signed-off-by: David S. Miller <davem@davemloft.net>

Accomplish this by using local variables.
Signed-off-by: David S. Miller <davem@davemloft.net>

This indicates if the NOOP scheduler is what is active for TX on a
given device.
Signed-off-by: David S. Miller <davem@davemloft.net>

First, we add a qdisc_tx_changing() helper which returns true if the
qdisc attachment is in transition.

Second, we remove an assertion warning which is of limited value and
is hard to express precisely in a multiqueue environment.
Signed-off-by: David S. Miller <davem@davemloft.net>

This is a helper function, currently used by IRDA.

This is being added so that we can contain and isolate as many
explicit ->tx_queue references in the tree as possible.
Signed-off-by: David S. Miller <davem@davemloft.net>

Isolate callers that want to simply reset all the TX qdiscs from the
details of TX queues.

Use this in the ISDN code.
Signed-off-by: David S. Miller <davem@davemloft.net>

We schedule queues, not the device, for output queue processing in BH.
Signed-off-by: David S. Miller <davem@davemloft.net>

It just wants the root qdisc given an arbitrary qdisc,
and that is simply qdisc->dev_queue->qdisc
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>

It is always equal to qdisc->dev_queue->lock
Signed-off-by: David S. Miller <davem@davemloft.net>

Now that our qdisc management is bi-directional, per-queue, and fully
orthogonal, there is no reason to have a special ingress qdisc pointer
in struct net_device.
Signed-off-by: David S. Miller <davem@davemloft.net>

Now qdisc, qdisc_sleeping, and qdisc_list also live there.
Signed-off-by: David S. Miller <davem@davemloft.net>

Every qdisc is assosciated with a queue, and in the case of ingress
qdiscs that will now be netdev->rx_queue so using that queue's lock is
the thing to do.
Signed-off-by: David S. Miller <davem@davemloft.net>

The lock is now an attribute of the device queue.

One thing to notice is that "suspicious" places
emerge which will need specific training about
multiple queue handling.  They are so marked with
explicit "netdev->rx_queue" and "netdev->tx_queue"
references.
Signed-off-by: David S. Miller <davem@davemloft.net>

It can be obtained via the netdev_queue.  So create a helper routine,
qdisc_dev(), to make the transformations nicer looking.

Now, qdisc_alloc() now no longer needs a net_device pointer argument.
Signed-off-by: David S. Miller <davem@davemloft.net>

A netdev_queue is an entity managed by a qdisc.

Currently there is one RX and one TX queue, and a netdev_queue merely
contains a backpointer to the net_device.

The Qdisc struct is augmented with a netdev_queue pointer as well.

Eventually the 'dev' Qdisc member will go away and we will have the
resulting hierarchy:

	net_device --> netdev_queue --> Qdisc

Also, qdisc_alloc() and qdisc_create_dflt() now take a netdev_queue
pointer argument.
Signed-off-by: David S. Miller <davem@davemloft.net>

We haven't had netdev->tbusy in many years :)
Signed-off-by: David S. Miller <davem@davemloft.net>

Conflicts:

	drivers/net/wireless/iwlwifi/iwl-3945.c
	net/mac80211/mlme.c

- vlan_dev_reorder_header() is only called on the receive path after
  calling skb_share_check(). This means we can use skb_cow() since
  all we need is a writable header.

- vlan_dev_hard_header() includes a work-around for some apparently
  broken out of tree MPLS code. The hard_header functions can expect
  to always have a headroom of at least there own hard_header_len
  available, so the reallocation check is unnecessary.

- __vlan_put_tag() can use skb_cow_head() to avoid the skb_unshare()
  copy when the header is writable.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Consider the following scenario:

ipv6_del_addr(ifp)
  ipv6_ifa_notify(RTM_DELADDR, ifp)
    ip6_del_rt(ifp->rt)

after returning from the ipv6_ifa_notify and enabling BH-s
back, but *before* calling the addrconf_del_timer the 
ifp->timer fires and:

addrconf_dad_timer(ifp)
  addrconf_dad_completed(ifp)
    ipv6_ifa_notify(RTM_NEWADDR, ifp)
      ip6_ins_rt(ifp->rt)

then return back to the ipv6_del_addr and:

in6_ifa_put(ifp)
  inet6_ifa_finish_destroy(ifp)
    dst_release(&ifp->rt->u.dst)

After this we have an ifp->rt inserted into fib6 lists, but 
queued for gc, which in turn can result in oopses in the
fib6_run_gc. Maybe some other nasty things, but we caught 
only the oops in gc so far.

The solution is to disarm the ifp->timer before flushing the
rt from it.
Signed-off-by: Andrey Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Although I only tested similar code (I don't use any of this wireless
code), the state maintainance between Netlink dump callback invocations
seems wrong here and should lead to an endless loop. There are also other
examples in the same file which might have the same problem. Perhaps someone
can actually test this (or refute my logic).

Take the simple example with only one element in the list (which should fit
into the message):

1. invocation:
  Start:
    idx = 0, start = 0
  Loop:
    condition (++idx < start) => (1 < 0) => false
    => no continue, fill one entry, exit loop, return skb->len > 0

2. invocation:
  Start:
    idx = 0, start = 1
  Loop:
    condition (++idx < start) => (1 < 1) => false
    => no continue, fill the same entry again, exit loop, return skb->len > 0

3. invocation:
  Same as 2. invocation, endless invocation of callback.

Also, iterations where the filling of an element fails should not be counted as
completed, so idx should not be incremented in this case.
Signed-off-by: Julius Volz <juliusv@google.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Some early versions of RTL8187B devices have a USB ID of 0x8187
rather than the 0x8189 of later models. In addition, it appears
that these early units also must be programmed with lower power.
Previous patches used the Product ID string to detect this situation,
but did not address the low power question. This patch uses the
hardware version and sets the power accordingly.
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix some register documentation in the register header files.
This allows better parsing by userspace scripts which in turn
helps debugging.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The gcc 3.4 fork used to compile the MN10300 port emits unwanted
__ucmpdi2() calls for switch statements that use a 64bit value.

This patch removes such a switch from b43legacy, and makes the code
more like that used in b43. Thanks to Adrian Bunk <bunk@kernel.org>
for reporting the problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2400 is the only currently available rt2x00 driver which
supports reporting of the RX end time for frames.
Since mac80211 uses this information for IBSS syncing, it
is important that it is being reported.

v2: Complement 32 bits of RX timestamp with upper 32bits from TSF
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Remove the rt2x00 singlethreaded workqueue and move
the link tuner and packet filter scheduled work to
the ieee80211_hw->workqueue again.
The only exception is the interface scheduled work
handler which uses the mac80211 interface iterator
under the RTNL lock. This work needs to be handled
on the kernel workqueue to prevent lockdep issues.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We only need 4 bytes of headroom for alignment
purposes in the RX frame. It was previously higher
for optimization purposes which are no longer
possible due to DMA mappings.

v2: Fix patch error
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

With the new rfkill interface there is no longer a need
for the input_polldev. Create a delayed_work structure
which we can put on the mac80211 workqueue and poll the
hardware every 1000ms.

v2: Decrease poll frequency from 100ms to 1000ms
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add some error checking to the new beacon configuration code.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix more than 50 kernel-doc warnings in ieee80211/mac80211 kernel-doc notation.
Fix a few typos also.

Note: Some fields are marked as TBD and need to have their description
corrected.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rfkill_add_switch() calls rfkill_toggle_radio() to set the state of a
recently registered rfkill class to the current global state [for that
rfkill->type].

The rfkill_toggle_radio() call is going to error out if the hardware is
RFKILL_STATE_HARD_BLOCKED, and the global state is RFKILL_STATE_UNBLOCKED.

That is a quite normal situation which I missed to account for.  As things
stand, the error return from rfkill_toggle_radio ends up causing
rfkill_register to bail out with an error (de-registering the new switch in
the process), which is Not Nice.

Change rfkill_add_switch() to not return errors because of a failed call to
rfkill_toggle_radio().  We can go back to returning errors again (if that's
indeed the right thing to do) if we define the exact error codes the
rfkill->toggle_radio callbacks are to return in each situation, so that we
can ignore the right ones only.

Bug reported by "kionez <kionez@anche.no>".
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: kionez <kionez@anche.no>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Improve rfkill_toggle_radio's kernel-doc header a bit.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>