Yevgeny Petrilin [Sat, 20 Jun 2009 22:15:52 +0000 (22:15 +0000)]
mlx4_en: Cancel port_up check in transmit function
When closing the port, we stop all transmit queues under the transmit
lock. It ensures that we will not attempt to transmit new packets after
the physical port was closed.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
David Brownell [Sat, 20 Jun 2009 08:21:53 +0000 (01:21 -0700)]
usbnet cdc_subset: fix issues talking to PXA gadgets
The host-side CDC subset driver is binding more specifically
than it should ... only to PXA 210/25x/26x Linux-USB gadgets.
Loosen that restriction to match the gadget driver driver.
This will various PXA 27x and PXA 3xx devices happier when
talking to Linux hosts, potentially others.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Tested-by: Aric D. Blumer <aric@sdgsystems.com> Signed-off-by: David S. Miller <davem@davemloft.net>
I recently got a report of an oops on a route lookup. Maxime was
testing what would happen if route caching was turned off (doing so by setting
making rt_caching always return 0), and found that it triggered an oops. I
looked at it and found that the problem stemmed from the fact that the route
lookup routines were returning success from their lookup paths (which is good),
but never set the **rp pointer to anything (which is bad). This happens because
in rt_intern_hash, if rt_caching returns false, we call rt_drop and return 0.
This almost emulates slient success. What we should be doing is assigning *rp =
rt and _not_ dropping the route. This way, during slow path lookups, when we
create a new route cache entry, we don't immediately discard it, rather we just
don't add it into the cache hash table, but we let this one lookup use it for
the purpose of this route request. Maxime has tested and reports it prevents
the oops. There is still a subsequent routing issue that I'm looking into
further, but I'm confident that, even if its related to this same path, this
patch makes sense to take.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg [Thu, 18 Jun 2009 15:23:43 +0000 (17:23 +0200)]
cfg80211: validate station settings
When I disallowed interfering with stations on non-AP interfaces,
I not only forget mesh but also managed interfaces which need
this for the authorized flag. Let's actually validate everything
properly.
This fixes an nl80211 regression introduced by the interfering,
under which wpa_supplicant -Dnl80211 could not properly connect.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Andrey Yurovsky [Tue, 16 Jun 2009 23:09:37 +0000 (16:09 -0700)]
cfg80211: allow setting station parameters in mesh
Mesh Point interfaces can also set parameters, for example plink_open is
used to manually establish peer links from user-space (currently via
iw). Add Mesh Point to the check in nl80211_set_station.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Andrey Yurovsky [Tue, 16 Jun 2009 18:31:04 +0000 (11:31 -0700)]
cfg80211: allow adding/deleting stations on mesh
Commit b2a151a288 added a check that prevents adding or deleting
stations on non-AP interfaces. Adding and deleting stations is
supported for Mesh Point interfaces, so add Mesh Point to that check as
well.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jiri Slaby [Thu, 18 Jun 2009 23:06:45 +0000 (01:06 +0200)]
ath5k: fix beacon_int handling
73ca5203366235f8a43e490767284ba8cfd8c479
(ath5k: remove conf->beacon_int usage)
removed bintval setting from ath5k_config. We need to init the
interval earlier and don't touch it in add_interface anymore.
Otherwise it will be set only once by upper layer through
bss_info_changed but not on second and further hostap executions.
We ended up having bintval 1000 which rendered the AP useless on
many clients.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <lrodriguez@atheros.com> Cc: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Troy Moure [Wed, 17 Jun 2009 10:51:56 +0000 (11:51 +0100)]
acer-wmi: fix rfkill conversion
"rfkill: rewrite" incorrectly reversed
the meaning of 'state' in acer_rfkill_update() when it changed
rfkill_force_state() to rfkill_set_sw_state(). Fix it.
Signed-off-by: Troy Moure <twmoure@szypr.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Tue, 16 Jun 2009 08:59:23 +0000 (11:59 +0300)]
ath5k: avoid PCI FATAL interrupts by restoring RETRY_TIMEOUT disabling
This reverts 'ath5k: remove dummy PCI "retry timeout" fix' on the
same theory as in 'ath9k: Fix PCI FATAL interrupts by restoring
RETRY_TIMEOUT disabling'.
Reported-by: Bob Copeland <me@bobcopeland.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Jenkins [Tue, 16 Jun 2009 13:54:04 +0000 (14:54 +0100)]
rfkill: export persistent attribute in sysfs
This information allows userspace to implement a hybrid policy where
it can store the rfkill soft-blocked state in platform non-volatile
storage if available, and if not then file-based storage can be used.
Some users prefer platform non-volatile storage because of the behaviour
when dual-booting multiple versions of Linux, or if the rfkill setting
is changed in the BIOS setting screens, or if the BIOS responds to
wireless-toggle hotkeys itself before the relevant platform driver has
been loaded.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Jenkins [Tue, 16 Jun 2009 13:53:52 +0000 (14:53 +0100)]
eeepc-laptop: read rfkill soft-blocked state on resume
This will respect state changes over hibernation, e.g. if the user
disables the wireless in the BIOS setup screen.
It reveals an issue where ACPI silently kills the wireless on
suspend. Normally, the BIOS restores the correct state from
non-volatile storage on boot. But when hibernation is aborted,
the wireless would remain killed. Fortunately we can work around
this in the resume handler by simply writing back the same value we
read from NVS.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Jenkins [Tue, 16 Jun 2009 14:39:51 +0000 (15:39 +0100)]
rfkill: don't restore software blocked state on persistent devices
The setting of the "persistent" flag is also made more explicit using
a new rfkill_init_sw_state() function, instead of special-casing
rfkill_set_sw_state() when it is called before registration.
Suspend is a bit of a corner case so we try to get away without adding
another hack to rfkill-input - it's going to be removed soon.
If the state does change over suspend, users will simply have to prod
rfkill-input twice in order to toggle the state.
Userspace policy agents will be able to implement a more consistent user
experience. For example, they can avoid the above problem if they
toggle devices individually. Then there would be no "global state"
to get out of sync.
Currently there are only two rfkill drivers with persistent soft-blocked
state. thinkpad-acpi already checks the software state on resume.
eeepc-laptop will require modification.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Marcel Holtmann <marcel@holtmann.org> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Jenkins [Tue, 16 Jun 2009 13:53:24 +0000 (14:53 +0100)]
rfkill: rfkill_set_block() when suspended nitpick
If we return after fiddling with the state, userspace will see the
wrong state and rfkill_set_sw_state() won't work until the next call to
rfkill_set_block(). At the moment rfkill_set_block() will always be
called from rfkill_resume(), but this will change in future.
Also, presumably the point of this test is to avoid bothering devices
which may be suspended. If we don't want to call set_block(), we
probably don't want to call query() either :-).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Tue, 16 Jun 2009 08:59:23 +0000 (11:59 +0300)]
ath9k: Fix PCI FATAL interrupts by restoring RETRY_TIMEOUT disabling
An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
code that was documented to disable RETRY_TIMEOUT register (PCI reg
0x41) since it was claimed to be a no-op. However, it turns out that
there are some combinations of hosts and ath9k-supported cards for
which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
code (or something similar) is needed. In such cases, the driver may
be next to unusable due to very frequent PCI FATAL interrupts from the
card.
Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
disabling, seems to resolve the issue. Since the removal of this code
was not based on any known issue and was purely a cleanup change, the
safest option here is to just revert that commit. Should there be
desire to clean this up in the future, the change will need to be
tested with a more complete coverage of cards and host systems.
http://bugzilla.kernel.org/show_bug.cgi?id=13483
Cc: stable@kernel.org Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hin-Tak Leung [Tue, 16 Jun 2009 02:15:56 +0000 (03:15 +0100)]
zd1211rw: adding 083a:e503 as a ZD1211B device
Hans Pontar reported success on the sourceforge zd1211-devs mailing list.
The device is branded "Arcor Easy Stick A 50 WLAN" (device manufactured
by SMC for a German ISP - SMC model name: WN4501H-LF-IR). General
information and Windows driver are available under (German only):
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net> Tested-by: Hans Pontar <pontar@gmx.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Mon, 15 Jun 2009 19:59:49 +0000 (21:59 +0200)]
iwmc3200wifi: add a mutex to protect iwm_reset_worker
The patch adds a mutex to protect the iwm_reset_worker against netdev
ndo_open and ndo_stop because all of them call iwm_up and iwm_down in
the implementation. Note the latter two are already protected by
rtnl. So if iwm_reset_worker is not required in the future, the mutex
can also be removed.
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Mon, 15 Jun 2009 19:59:48 +0000 (21:59 +0200)]
iwmc3200wifi: fix potential kernel oops on module removal
The iwm_if_free() is called before destroy_workqueue for isr_wq on
device remove method. But if there is still some pending work in
the isr_wq, the required data structures are already freed at this
point. This leeds a kernel oops. The patch fixes this problem by
moving iwm_if_free after destroy_workqueue.
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Mon, 15 Jun 2009 19:36:14 +0000 (21:36 +0200)]
iwmc3200wifi: add iwm_if_add and iwm_if_remove
We used to do alloc_netdev and register_netdev at the same time in
iwm_if_alloc. But some bus related structures will only be initialized
after iwm_priv is allocated. This caused a race condition that the
netdev might be registered earlier. The patch adds iwm_if_add and
iwm_if_remove so that the bus layer could register the device after
all initialization is done.
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Mon, 15 Jun 2009 19:36:13 +0000 (21:36 +0200)]
iwmc3200wifi: check for iwm_priv_init error
We need to check for iwm_priv_init() errors and do proper cleanups.
Otherwise we may fail to catch the create_singlethread_workqueue()
error which will cause a kernel oops when destroy_workqueue() later.
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mv643xx_eth: fix unicast filter programming in promiscuous mode
The Unicast Promiscious Mode (UPM) bit in the mv643xx_eth port
configuration register doesn't do exactly what its name would suggest:
setting this bit merely enables reception of all unicast frames with a
destination address that differs from our local MAC address in bits
[47:4]. In particular, it doesn't have any effect on unicast frames
with a destination address that matches our MAC address in bits [47:4]
-- these will still be tested against the 16-entry unicast address
filter table.
Therefore, if the interface is set to promiscuous mode, just setting
the unicast promiscuous bit isn't enough -- we need to set all filter
bits in the unicast filter table to 1 as well.
Reported-by: Sachin Sanap <ssanap@marvell.com> Signed-off-by: Prabhanjan Sarnaik <sarnaik@marvell.com> Tested-by: Siddarth Gore <gores@marvell.com> Tested-by: Mahavir Jain <mjain@marvell.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
e1000e: commonize tx cleanup routine to match e1000 & igb
changed the logic for determining if we should call napi_complete or
not at then end of a napi poll.
If the NIC is using MSI-X with no work to do in ->poll, net_rx_action
can just spin indefinitely on older kernels and for 2 jiffies on newer
kernels since napi_complete is never called and budget isn't
decremented.
Discovered and verified while testing driver backport to an older
kernel.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sathya Perla [Thu, 18 Jun 2009 00:05:54 +0000 (00:05 +0000)]
be2net: Use MCC queue for cmds that may be called in BH context
Currenlty multicast_set and promiscuous_config cmds -- that may be called in BH context --
use the blocking MCC mbox to post cmds.
An mbox cmd is protected via a spin_lock(cmd_lock) and not spin_lock_bh() as it is undesirable
to disable BHs while a blocking mbox cmd is in progress (and take long to finish.)
This can lockup a cmd in progress in process context.
So, these two cmds in BH context must use the MCC queue to post cmds.
Signed-off-by: Sathya Perla <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sathya Perla [Thu, 18 Jun 2009 00:02:59 +0000 (00:02 +0000)]
be2net: Add MCC queue mechanism for BE cmds
Currenlty all cmds use the blocking MCC mbox to post cmds. An mbox cmd is protected
via a spin_lock(cmd_lock) and not spin_lock_bh() as it is undesirable
to disable BHs while a blocking mbox cmd is in progress (and take long to finish.)
This can lockup a cmd in progress in process context. Instead cmds that may be
called in BH context must use the MCC queue to post cmds. The cmd completions
are rcvd in a separate completion queue and the events are placed in the tx-event
queue.
Signed-off-by: Sathya Perla <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
af_iucv: Return -EAGAIN if iucv msg limit is exceeded
If the iucv message limit for a communication path is exceeded,
sendmsg() returns -EAGAIN instead of -EPIPE.
The calling application can then handle this error situtation,
e.g. to try again after waiting some time.
For blocking sockets, sendmsg() waits up to the socket timeout
before returning -EAGAIN. For the new wait condition, a macro
has been introduced and the iucv_sock_wait_state() has been
refactored to this macro.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
af_iucv: Change if condition in sendmsg() for more readability
Change the if condition to exit sendmsg() if the socket in not connected.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dhananjay Phadke [Wed, 17 Jun 2009 17:27:25 +0000 (17:27 +0000)]
netxen: fix tx ring accounting
This forces every update of tx ring producer to check for
availability of space for next full TSO command. Earlier
firmware control commands didn't care to pause tx queue.
Stop the tx queue if there's not enough space to transmit one full
LSO command left on the tx ring after current transmit. This avoids
returning NETDEV_TX_BUSY after checking distance between producer
and consumer on every cpu.
Restart the tx queue only if we have cleaned up enough tx
descriptors.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Net / e100: Fix suspend of devices that cannot be power managed
If the adapter is not power-manageable using either ACPI, or the
native PCI PM interface, __e100_power_off() returns error code, which
causes every attempt to suspend to fail, although it should return 0
in such a case. Fix this problem by ignoring the return value of
pci_set_power_state() in __e100_power_off().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Andreas Mohr <andi@lisas.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Pirko [Wed, 17 Jun 2009 01:12:19 +0000 (01:12 +0000)]
net: group address list and its count
This patch is inspired by patch recently posted by Johannes Berg. Basically what
my patch does is to group list and a count of addresses into newly introduced
structure netdev_hw_addr_list. This brings us two benefits:
1) struct net_device becames a bit nicer.
2) in the future there will be a possibility to operate with lists independently
on netdevices (with exporting right functions).
I wanted to introduce this patch before I'll post a multicast lists conversion.
Jarek Poplawski [Thu, 18 Jun 2009 07:28:51 +0000 (00:28 -0700)]
ipv4: Fix fib_trie rebalancing, part 2
My previous patch, which explicitly delays freeing of tnodes by adding
them to the list to flush them after the update is finished, isn't
strict enough. It treats exceptionally tnodes without parent, assuming
they are newly created, so "invisible" for the read side yet.
But the top tnode doesn't have parent as well, so we have to exclude
all exceptions (at least until a better way is found). Additionally we
need to move rcu assignment of this node before flushing, so the
return type of the trie_rebalance() function is changed.
Reported-by: Yan Zheng <zheng.yan@oracle.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jarek Poplawski [Tue, 16 Jun 2009 08:33:55 +0000 (08:33 +0000)]
pkt_sched: Update drops stats in act_police
Action police statistics could be misleading because drops are not
shown when expected.
With feedback from: Jamal Hadi Salim <hadi@cyberus.ca>
Reported-by: Pawel Staszewski <pstaszewski@itcare.pl> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
Reduce the size of the driver transmit ring to reduce latency
and allow qdisc to do better rate control. Also make it
obvious what the minimum transmit ring allowed is and why.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The logic in sky2_down was incorrect. Receiver could report status
after rx_stop was called.
The steps need to be:
* stop new frames from being transmitted
* shut off transmit/receive logic
* synchronize with NAPI to process status info about transmitter
and receiver
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
françois romieu [Wed, 17 Jun 2009 11:41:45 +0000 (11:41 +0000)]
r8169: do not bring device down when suspending
Stopping all activity through ChipCmd and blindly acking the irqs
is neither nice nor completely needed: the transition to low-power
mode does enough work and it apparently keeps the device in a sane
state.
Patch suggested by a fix for http://bugzilla.kernel.org/show_bug.cgi?id=9512
The rtl_shutdown path is kept unchanged so far.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Anders Eriksson <aeriksson@fastmail.fm> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
françois romieu [Wed, 17 Jun 2009 11:43:11 +0000 (11:43 +0000)]
sis190: use an adequate phy list entry as a fallback
When sis190 driver is trying to get default phy, if it doesn't find home
or lan phy, it falls back to the first phy in the phy list but list_entry()
points to a bogus entry. list_first_entry() should be used instead.
Signed-off-by: Arnaud Patard <apatard@mandriva.com> Acked-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch meshes badly with "net: Rework ucc_geth driver to use
of_mdio infrastructure" (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
The skb mac_header field is sometimes NULL (or ~0u) as a sentinel
value. The places where skb is expanded add an offset which would
change this flag into an invalid pointer (or offset).
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
skbuff: skb_mac_header_was_set is always true on >32 bit
Looking at the crash in log_martians(), one suspect is that the check for
mac header being set is not correct. The value of mac_header defaults to
0 on allocation, therefore skb_mac_header_was_set will always be true on
platforms using NET_SKBUFF_USES_OFFSET.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Some protocols check sk_wmem_alloc value to determine if a timer
must delay socket deallocation. We must take care of the sk_wmem_alloc
value being one instead of zero when no write allocations are pending.
Reported by Ingo Molnar, and full diagnostic from David Miller.
This patch introduces three helpers to get read/write allocations
and a followup patch will use these helpers to report correct
write allocations to user.
Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Fix up remaining drivers returning a magic or an errno value from their
ndo_start_xmit() functions that were missed in the first pass:
- isdn_net: missed conversion
- bpqether: missed conversion: skb is freed, so return NETDEV_TX_OK
- hp100: intention appears to be to resubmit skb once resources are
available, but due to no queue handling it is dropped for now.
- lapbether: skb is freed, so return NETDEV_TX_OK
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
- Enabled SRIOV support in the driver.
- Call __vxge_hw_verify_pci_e_info() for the PF only. This function
verifies the negotiated link width and current link speed in the
Link Status Register (offset 12h) which are reserved fields for VFs
as per the SRIOV specification, section 3.5.8.
- Implemented David Miller's comment to remove the #ifdef CONFIG_PCI_IOV as
these intefaces have NOP versions declared when the defintion is not set.
Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com> Signed-off-by: Rastapur Santosh <santosh.rastapur@neterion.com> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The code to compute VPD size didn't handle some systems that use
chip without VPD. Also some of the newer chips use some additional
registers to store the actual size, and wasn't worth putting the
additional complexity in, so just remove the code.
No big loss since the code to set the VPD size was only a
convenience so that utilities would not read the extra space past
the end of the available VPD.
Move the first PCI config read earlier to detect bad hardware
where it returns all ones and refuse loading driver before furthur
damage.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Tested-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg [Mon, 15 Jun 2009 16:13:58 +0000 (18:13 +0200)]
mac80211: fix wext bssid/ssid setting
When changing to a new BSSID or SSID, the code in
ieee80211_set_disassoc() needs to have the old data
still valid to be able to disconnect and clean up
properly. Currently, however, the old data is thrown
away before ieee80211_set_disassoc() is ever called,
so fix that by calling the function _before_ the old
data is overwritten.
This is (one of) the issue(s) causing mac80211 to hold
cfg80211's BSS structs forever, and them thus being
returned in scan results after they're long gone.
Johannes Berg [Mon, 15 Jun 2009 14:26:47 +0000 (16:26 +0200)]
dell-laptop: fix rfkill conversion
A polarity error snuck into the rfkill rewrite's dell-laptop
conversion, fix it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 15 Jun 2009 11:42:25 +0000 (13:42 +0200)]
mac80211: disconnect when user changes channel
If we do not disconnect when a channel switch is requested,
we end up eventually detection beacon loss from the AP and
then disconnecting, without ever really telling the AP, so
we might just as well disconnect right away.
Additionally, this fixes a problem with iwlwifi where the
driver will clear some internal state on channel changes
like this and then get confused when we actually go clear
that state from mac80211.
It may look like this patch drops the no-IBSS check, but
that is already handled by cfg80211 in the wext handler it
provides for IBSS (cfg80211_ibss_wext_siwfreq).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Sun, 14 Jun 2009 15:37:39 +0000 (17:37 +0200)]
mac80211: add queue debugfs file
I suspect that some driver bugs can cause queues to be
stopped while they shouldn't be, but it's hard to find
out whether that is the case or not without having any
visible information about the queues. This adds a file
to debugfs that allows us to see the queues' statuses.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Nick Kossifidis [Fri, 12 Jun 2009 23:09:53 +0000 (16:09 -0700)]
ath5k: fix mesh beaconing
This patch is from Nick Kossifidis but he forgot to send it. It ensures
that the beacon queue gets started in mesh mode as well, otherwise ath5k
will not beacon in mesh point mode.
At this time, we still need to issue a scan before mesh beaconing will
work but that appears to be a separate problem.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Signed-off-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Abhijeet Kolekar [Fri, 12 Jun 2009 20:22:52 +0000 (13:22 -0700)]
iwlwifi/iwl3945: fix suspend resume association bug
Patch fixes the following bugs at
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2005
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2007
If we suspend with an association and then resumed,
we need to synchronize the active rxon with staging rxon,
else we will get an error when iwl_alive_start try to commit
rxon and staging is set to channel 0. Before going to suspend
staging and active rxon are in sync. After resuming from the
suspend, iwl_mac_start is called and it clears the staging
rxon. Patch fixes the bug by not clearing the staging rxon
in iwl_mac_start.
Patch also adds similar fix to 3945.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wey-Yi Guy [Fri, 12 Jun 2009 20:22:51 +0000 (13:22 -0700)]
iwlwifi: check for channel location for 40MHz
for both mixed and pure 40MHz, need to check for valid channel location.
if the specified channel not allow the channel location requested
(ABOVE, BELOW), then reject the Fat channel access
This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1988
("iwlwifi: checking for 40MHz mode" and "iwlwifi: check control channel
for pure 40MHz" combine with this to address the above bug. -- JWL)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wey-Yi Guy [Fri, 12 Jun 2009 20:22:50 +0000 (13:22 -0700)]
iwlwifi: check control channel for pure 40MHz
for pure 40MHz mode, set the control channel location if provided, but not
like Mixed mode; if information is not provided, still allow 40MHz
operation.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wey-Yi Guy [Fri, 12 Jun 2009 20:22:49 +0000 (13:22 -0700)]
iwlwifi: checking for 40MHz mode
when checking for 40MHz, compare ht_protection to
IEEE80211_HT_OP_MODE_PROTECTION_20MHZ. ht_protection is not a bit-mask
field
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 12 Jun 2009 20:22:48 +0000 (13:22 -0700)]
iwlwifi: revamp bss_info_changed
My earlier patch,
"mac80211: unify config_interface and bss_info_changed"
introduced a bug in iwlwifi where it will do some things
incorrectly now when reassociating.
Revamp iwl_bss_info_changed to fix that issue and make it
easier to read. Also, while at it, add comments about things
that it should do but currently doesn't.
Finally, also improve the locking in the function.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Andrey Yurovsky [Fri, 12 Jun 2009 19:45:36 +0000 (12:45 -0700)]
libertas: fix IEEE PS mode in GSPI driver
The card firmware does not set the Command Download Ready interrupt bit
when IEEE PS mode is enabled, preventing the driver from sending
commands (such as the command to exit IEEE PS mode) since there is no
indication that the card is ready to accept commands.
This patch works around the problem by using the the TX Download Ready
bit in place of the Command Download Ready Bit while in IEEE PS mode.
TX Download Ready is set in IEEE PS mode.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Thu, 11 Jun 2009 15:19:45 +0000 (18:19 +0300)]
mac80211: Do not try to associate with an empty SSID
It looks like some programs (e.g., NM) are setting an empty SSID with
SIOCSIWESSID in some cases. This seems to trigger mac80211 to try to
associate with an invalid configuration (wildcard SSID) which will
result in failing associations (or odd issues, potentially including
kernel panic with some drivers) if the AP were to actually accept this
anyway).
Only start association process if the SSID is actually set. This
speeds up connection with NM in number of cases and avoids sending out
broken association request frames.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 11 Jun 2009 10:08:15 +0000 (12:08 +0200)]
sony: fix rfkill code again
When the hard state changes, we shouldn't set the soft
state to blocked as well -- we have no such indication
from the device in that case so leave it untouched.
projects / linux-beck.git / log