The Tx DMA descriptor has two kinds of flags that select RTS/CTS usage.
The first one (global for the frame) selects whether RTS/CTS or
CTS-to-self should be used, the second one enables RTS/CTS or
CTS-to-self usage for an individual multi-rate-retry entry.
Previously the code preparing the descriptor only enabled the global
flag, if the first MRR series selected the local one.
Fix this by enabling the global flag if any of the MRR entries need it.
With this patch, rate control can properly select the use of RTS/CTS
for all MRR entries except the first one, which is the default behavior.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Future code will need to look up rdev and wdev
within atomic sections, but currently we need
to lock a mutex for such lookups. Change the
list handling for both to be RCU-safe so that
we can look them up in rcu sections instead in
the future.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In an earlier commit,
mac80211: disable software retry for now
Pavel Roskin reported a problem that seems to be due to
software retry of already transmitted frames. It turns
out that we've never done that correctly, but due to
some recent changes it now crashes in the TX code. I've
added a comment in the patch that explains the problem
better and also points to possible solutions -- which
I can't implement right now.
I disabled software retry of failed/filtered frames
because it was broken. With the work of the previous
patches, it now becomes fairly easy to re-enable it
by adding a flag indicating that the frame shouldn't
be modified, but still running it through the transmit
handlers to populate the control information.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When mac80211 asks a driver to encrypt a frame, it
must assign the control.hw_key pointer for it to
know which key to use etc. Currently, mac80211 does
this whenever it would software-encrypt a frame.
Change the logic of this code to assign the hw_key
pointer when selecting the key, and later check it
when deciding whether to encrypt the frame or let
it be encrypted by the hardware. This allows us to
later simply skip the encryption function since it
no longer modifies the TX control.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no value in setting a flag that will
never be checked after this point, this seems
to be legacy code -- I think previously the
flag was used to check whether to encrypt the
frame or not. Now, however, the flag need not
be set, and setting it actually interferes if
the frame will be processed again later.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an skb survived a round-trip through the driver
and needs to be re-used, its control information is
definitely not valid any more, the driver will have
overwritten it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This TX handler is used only for assigning the
station pointer in the control information, so
give it a better name. Also move it before rate
control.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Code directly scaling by HZ and rounding can be more efficiently
and clearly performed with msecs_to_jiffies.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When reading current ucode statistics information from debugfs, in
current implementation, it will always send a new "statistics request" to
uCode. In normal operation, uCode should report the statistics per beacon
interval. Remove this extra request to reduce the additional command exchanges
between driver and uCode.
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>
Flowhandler handle the communication between driver and uCode, when any
uCode error happen, we also like to know what is the status of the
flowhandler; it can help to debug flowhandler related problem.
Also adding debugfs file to dump current value of flowhandler registers.
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>
This is a w/a for a hardware bug. the h/w bug may cause the Rx bit
(bit 15 before shifting it to 31) to clear when using interrupt coalescing.
This does not mean frames are lost - their processing is just delayed until
next interrupt arrives.
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>
For interrupt coalescing timer, the CSR_INT_COALESCING is an 8 bit
register in 32-usec unit, the range can go from 0x00 - 0xFF. set the
range and default timeout value for both calibration mode and operation mode.
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>
When dumping event log in debugfs, iwl_dump_nic_event_log()
should return the correct error code instead of let the calling
function makes it own assumption.
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>
When uCode detects number of beacon missed consecutively above the
internal missed beacon threshold (set by uCode), it will reset and
re-tune the radio in order to get out of bad PHY state.
This "num_of_sos_states" counter monitors number of time uCode
encounters this bad condition and has to re-tune the radio.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To help debug uCode related problem, adding "delta" and "max"
information in debugfs statistics counters display.
Those information show the delta between two statistics report from
uCode, user can monitor the counters for any "un-normal" behavior.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Jay Sternberg<jay.e.sternberg@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When receive reply statistics command with "clear" mask, just reset the
accumulated statistics counters, but not the current statistics counters,
so the accumulated statistics counter can provide the correct
information.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The WMM AC selection added to the monitor mode selection function
accidentally assigns non-QoS data frames to the same AC as mgmt frames
(VO). This is not serious, but should be fixed anyway. This patch
assigns them to the BE AC instead.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix check to verify if a register bit is set. We have not hit this bug because
wait_for_cmd_complete() is always called with S2IO_BIT_RESET.
Reported by Roel Kluin <roel.kluin@gmail.com>.
Signed-off-by: Ram Vepa <ram.vepa@neterion.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The comments in arm_machine_restart() suggest that cpu_proc_fin()
will clean and disable cache and turn off interrupts. This does
not seem to be implemented for proc-v7.S, implement it the same
way as for proc-v6.S.
This also makes kexec work for v7. Note that a related TLB and
branch traget flush patch is also needed to avoid kexec
"crc error".
Note that there are still some issues that seem to be related
to L2 cache being on and causing occasional uncompress "crc error"
with kexec. Anyways, this gets kexec mostly working on V7 for now.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We need to do that if we tinker with the MMU entries.
This fixes the occasional bug with kexec where the new
fails to uncompress with "crc error". Most likely at
least kexec on v6 and v7 need this fix.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Without this patch arch/arm/compressed/head.S defaults to generic
DCC code that does not work for v7.
For more information on the v7 DCC, see Cortex-A8 TRM
"12.11.1 Debug communications channel".
To use it with post 2.6.33-rc1 or later, you need to have:
CONFIG_DEBUG_LL=y
ONFIG_DEBUG_ICEDCC=y
CONFIG_EARLY_PRINTK=y
Earlier kernels need commit 93fd03a8c6
backported.
Tested on omap3430.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In a string like "v:SIP/2.0..." it was checking for !isalpha('S') when it
meant to be inspecting the ':'.
Patch by Greg Alexander <greqcs@galexander.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
fs/bio.c:81:33: warning: symbol 'bslab' shadows an earlier one
fs/bio.c:74:25: originally declared here
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
If the per device ARP_ACCEPT option is enable, currently we only allow
creating new ARP cache entries for response type gratuitous ARP.
Allowing gratuitous ARP to create new ARP entries (not only to update
existing ones) is useful when we want to avoid unnecessary delays for
the first packet of a stream.
This patch allows request type gratuitous ARP to create new ARP cache
entries as well. This is useful when we want to populate the ARP cache
entries for a large number of hosts on the same LAN.
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I was just looking at ppp_generic, and noticed that it fairly recently
(as in the last year) got rather mangled with many spaces turned into tabs
in places they very much shouldn't have been. I tracked it down to commit
9c705260fe (ppp: ppp_mp_explode() redesign).
I am amazed if that patch passed the patch checking script. I have no
idea what kind of weird editor setting did this, but it has to have been a
weird editor setting or a very unfortunate search and replace gone wrong.
I only found it trying to apply a patch I was playing with and wondering
why it wouldn't apply. Then I found there were tabs in the middle of
comments that used to be spaces.
Well here is a patch that should fix it up as far as I can tell.
Purely whitespace repair. No actual code changes.
Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
This driver tweaks VR_CTL, so pull in the header for the bit defines.
Also switch to the new define name as the old one has gone away.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Checking the PHY XS MMD here is unnecessary and can give false negatives.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 7583605b6d ("ucc_geth: Fix empty
TX queue processing") fixed empty TX queue mishandling, but didn't
account another corner case: when TX queue becomes full.
Without this patch the driver will stop transmiting when TX queue
becomes full since 'bd == ugeth->txBd[txQ]' actually checks for
two things: queue empty or full.
Let's better check for NULL skb, which unambiguously signals an empty
queue.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Stable <stable@vger.kernel.org> [2.6.32]
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 541cd3ee00 ("phylib: Fix deadlock
on resume") caused TI DaVinci EMAC ethernet driver to oops upon resume:
PM: resume of devices complete after 237.098 msecs
Restarting tasks ... done.
kernel BUG at kernel/workqueue.c:354!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
[...]
Backtrace:
[<c002c598>] (__bug+0x0/0x2c) from [<c0052a54>] (queue_delayed_work_on+0x74/0xf8)
[<c00529e0>] (queue_delayed_work_on+0x0/0xf8) from [<c0052b30>] (queue_delayed_work+0x2c/0x30)
The oops pops up because TI DaVinci EMAC driver detaches PHY on
suspend and attaches it back on resume. Attaching makes phylib call
phy_start_machine() that initializes a workqueue. On the other hand,
PHY's resume routine will call phy_start_machine() again, and that
will cause the oops since we just destroyed the already scheduled
workqueue.
This patch fixes the issue by moving workqueue initialization to
phy_device_create().
p.s. We don't see this oops with ucc_geth and gianfar drivers because
they perform a fine-grained suspend, i.e. they just stop the PHYs
without detaching.
Reported-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hey all-
I was tinkering with dccp recently and noticed that I BUG halted the
kernel when I rmmod-ed the dccp module. The bug halt occured because the page
that I passed to kfree failed the PageCompound and PageSlab test in the slub
implementation of kfree. I tracked the problem down to the following set of
events:
1) dccp, unlike all other uses of kmem_cache_create, allocates a string
dynamically when registering a slab cache. This allocated string is freed when
the cache is destroyed.
2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
caches are 'merged'. This process causes multiple caches of simmilar
configuration to use the same cache data structure. When this happens, the new
name of the cache is effectively dropped.
3) (2) results in kmem_cache_name returning an ambigous value (i.e.
ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
for freeing), is no longer guaranteed that the string it assigned is what is
returned.
4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
which trips over the BUG in the slub implementation of kfree (since its likely
not a slab allocation, but rather a pointer into the static string table
section.
So, what to do about this. At first blush this is pretty clearly a leak in the
information that slub owns, and as such a slub bug. Unfortunately, theres no
really good way to fix it, without exposing slub specific implementation details
to the generic slab interface. Also, even if we could fix this in slub cleanly,
I think the RCU free option would force us to do lots of string duplication, not
only in slub, but in every slab allocator. As such, I'd like to propose this
solution. Basically, I just move the storage for the kmem cache name to the
ccid_operations structure. In so doing, we don't have to do the kstrdup or
kfree when we allocate/free the various caches for dccp, and so we avoid the
problem, by storing names with static memory, rather than heap, the way all
other calls to kmem_cache_create do.
I've tested this out myself here, and it solves the problem quite well.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sh64 on the other hand provides both direct broken out syscalls as well
as socketcall access. As there are binaries that use both socketcall has
to stay around. The current ABI prefers direct syscalls.
It was pointed out that when sys_recvmmsg was added in, sys_accept4 was
overlooked. This takes care of wiring it up.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh32 at the moment only uses sys_socketcall to reach these, so unwire
recvmmsg for now. While we're at it, add it to the ignore list, as per
the s390 change.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
We can use logical flat mode if there are <= 8 logical cpu's
(irrespective of physical apic id values). This will enable simplified
and efficient IPI and device interrupt routing on such platforms.
This has been tested to work on both Intel and AMD platforms.
Exceptions like IBM summit platform which can't use logical flat mode
are addressed by using OEM platform checks.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Chris McDermott <lcm@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Chris McDermott from IBM confirmed that hurricane chipset in IBM summit
platforms doesn't support logical flat mode. Irrespective of the other
things like apic_id's, total number of logical cpu's, Linux kernel
should default to physical mode for this system.
The 32-bit kernel does so using the OEM checks for the IBM summit
platform. Add a similar OEM platform check for the 64bit kernel too.
Otherwise the linux kernel boot can hang on this platform under certain
bios/platform settings.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Tested-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Chris McDermott <lcm@linux.vnet.ibm.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: Remove warning message for invalid OSS minor ranges
ALSA: hda - Fix capture on Sony VAIO with single input
ALSA: hda - Fix mute led GPIO on HP dv-series notebooks
ALSA: use subsys_initcall for sound core instead of module_init
ALSA: hda - Fix missing capture mixer for ALC861/660 codecs
ALSA: hda - Improved MacBook (Pro) 5,1 / 5,2 support
ALSA: hda - Fix Toshiba NB20x quirk entry
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: Unlock mc13783 before subsystems initialisation, at probe time.
mfd: WM835x GPIO direction register is not locked
mfd: tmio_mmc hardware abstraction for CNF area
mfd: WM8350 off by one bug
mfd: Correct WM835x ISINK ramp time defines
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Move cpu hotplug driver lock from pseries to powerpc
powerpc: Move /proc/ppc64 to /proc/powerpc update
powerpc/8xx: Fix user space TLB walk in dcbX fixup
powerpc: Fix decrementer setup on 1GHz boards
powerpc/iseries: Initialise on-stack completion
powerpc/hvc: Driver build breaks with !HVC_CONSOLE
serial/pmac_zilog: Workaround problem due to interrupt on closed port
powerpc/macintosh: Make Open Firmware device id constant
powerpc: Use helpers for rlimits
powerpc: cpumask_of_node() should handle -1 as a node
powerpc/pseries: Fix dlpar compile warning without CONFIG_PROC_DEVICETREE
powerpc/pseries: Fix xics interrupt affinity
powerpc/swsusp_32: Fix TLB invalidation
powerpc/8xx: Always pin kernel instruction TLB
powerpc: 2.6.33 update of defconfigs for embedded 6xx/7xxx, 8xx, 8xxx
powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
powerpc/5200: update defconfigs
