Now sk_route_caps is u64, its dangerous to use an integer to store
result of an AND operator. It wont work if NETIF_F_SG is moved on the
upper part of u64.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the case where CONFIG_PSTORE=n, the function efi_pstore_read() doesn't
have the correct list of parameters. This patch provides a definition
of efi_pstore_read() with 'char **buf' added to fix this warning:
"drivers/firmware/efivars.c:609: warning: initialization from".
problem introduced in commit f6f8285132
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
We need to set np->mcast_hops to it's default value at this moment
otherwise when we use it and found it's value is -1, the logic to
get default hop limit doesn't take multicast into account and will
return wrong hop limit(IPV6_DEFAULT_HOPLIMIT) which is for unicast.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I just hit this during my testing. Isn't there another bug lurking?
BUG kmalloc-8: Redzone overwritten
INFO: 0xc0000000de9dec48-0xc0000000de9dec4b. First byte 0x0 instead of 0xcc
INFO: Allocated in .__seq_open_private+0x30/0xa0 age=0 cpu=5 pid=3896
.__kmalloc+0x1e0/0x2d0
.__seq_open_private+0x30/0xa0
.seq_open_net+0x60/0xe0
.dev_mc_seq_open+0x4c/0x70
.proc_reg_open+0xd8/0x260
.__dentry_open.clone.11+0x2b8/0x400
.do_last+0xf4/0x950
.path_openat+0xf8/0x480
.do_filp_open+0x48/0xc0
.do_sys_open+0x140/0x250
syscall_exit+0x0/0x40
dev_mc_seq_ops uses dev_seq_start/next/stop but only allocates
sizeof(struct seq_net_private) of private data, whereas it expects
sizeof(struct dev_iter_state):
struct dev_iter_state {
struct seq_net_private p;
unsigned int pos; /* bucket << BUCKET_SPACE + offset */
};
Create dev_seq_open_ops and use it so we don't have to expose
struct dev_iter_state.
[ Problem added by commit f04565ddf5 (dev: use name hash for
dev_seq_ops) -Eric ]
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'for-3.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessary
percpu: fix chunk range calculation
percpu: rename pcpu_mem_alloc to pcpu_mem_zalloc
The comments describing device power management callbacks in
include/pm.h are outdated and somewhat confusing, so make them
reflect the reality more accurately.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The system wakeup section of Documentation/power/devices.txt is
outdated, so make it agree with the current code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The runtime PM core code behavior related to the power.irq_safe
device flag has changed recently and the documentation should be
modified to reflect it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The documentation file Documentation/power/devices.txt contains some
information that isn't correct any more due to code modifications
made after that file had been created (or updated last time). Fix
this.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The current power management documentation in Documentation/power/
either doesn't cover PM domains at all, or gives inaccurate
information about them, so update the relevant files in there to
follow the code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Don't over-schedule QSFP work on driver initialization. It could end
up being run simultaneously on two different CPUs resulting in bad
EEPROM reads. In combination with setting the physical IB link state
prior to the IBC being brought out of reset, this can cause the link
state machine to start training early with wrong settings.
Signed-off-by: Mitko Haralanov <mitko@qlogic.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@qlogic.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Fix logic so that we don't retry with MPAv1 once we have done that
already. Otherwise, we end up retrying with MPAv1 even when its not
needed on getting peer aborts - and this could lead to kernel panic.
Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Fix another place in the code where logic dealing with the t4_cqe was
using the wrong QID. This fixes the counting logic so that it tests
against the SQ QID instead of the RQ QID when counting RCQES.
Signed-off by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off by: Steve Wise <swise@ogc.us>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Not sure it is the best way to do it, but many times we want to know what the
configuration options were enabled for the compiled driver.
Let's just log the options during load time; so there were be no confusion.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the uCode hasn't been released (yet?),
warn only if using older than API 4, but load
anything up to API 6.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes handling the calibration data more generic
and no longer requires updating IWL_CALIB_MAX when a
new uCode comes with more calibration packets. Since
we just copy the data back, there's also no need for
understanding which calibration we received -- we can
just reflect it back to the runtime uCode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The init microcode knows very well which calibrations
are required and sends us results for those that are.
Consequently, we can just send all of those to the RT
uCode again.
The problem with having the driver know about this is
that it is a uCode feature, not a hardware feature so
the config is completely unsuitable.
The only thing we need to check is whether the device
needs crystal calibration or not, add a new parameter
to the configuration for that.
This makes new uCode work on 6000 series devices.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Create new testmode commands to suppot indirect access
of peripheral register.
- IWL_TM_CMD_APP2DEV_INDIRECT_REG_READ32
- IWL_TM_CMD_APP2DEV_INDIRECT_REG_WRITE32
Meanwhile, add affix "DIRECT" into original register access
commands for better discrimination with new commands.
- IWL_TM_CMD_APP2DEV_DIRECT_REG_READ32
- IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE32
- IWL_TM_CMD_APP2DEV_DIRECT_REG_WRITE8
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Optimize ath5k_cw_validate by using the classic (X & (X - 1)) == 0
check to see if a number is power of 2.
v2: Use functions from log2.h instead
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to documentation higher DCUs have higher priority and should
be used for beacons and CAB traffic. More specifically DCU 9 should be
used for beacons and DCU 8 for CAB traffic, I assumed DCU 7 should be
OK for UAPSD traffic.
Note that DCU 8 and 9 are special because they can only be mapped to a single
QCU each but since we use a 1:1 mapping between QCUs and DCUs anyway we don't
have to change much.
P.S. I also did a few related cleanups on qcu.c and ath5k.h
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
MRR support and 2GHz radio override belong in ah_capabilities and we
should use them (e.g. so far we used to set mrr descriptor without
checking if MRR support is enabled + we checked for MRR support 2
times, one by trying to set up an MRR descriptor and another one based
on MAC version).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a module parameter to disable hw rf kill switch (GPIO interrupt) because
in some cases when the card doesn't come with the laptop, EEPROM configuration
doesn't match laptop's configuration and rf kill interrupt always fires up and
disables hw. I thought of moving this to debugfs and make it per-card but
this way it's easier for users and distros to handle.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no short calibration on AR5210, make sure we treat it always
as full calibration.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No functional changes
Add kernel doc for all ath5k_hw_* functions and strcucts. Also do some cleanup,
rename ath5k_hw_init_beacon to ath5k_hw_init_beacon_timers, remove an unused
variable from ath5k_hw_pcu_init and a few obsolete macros, mostly related to XR.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Noise floor calibration does not interfere with traffic and should run more
often as part of our "short calibration". The full calibration is not the
noise floor calibration but the AGC + Gain_F (on RF5111 and RF5112) calibration
and should run less often because it does interfere with traffic.
So
Short calibration -> I/Q & NF Calibration
Long calibration -> Short + AGC + Gain_F
This patch was for some time on my pub/ dir on www.kernel.org and has been tested
by a few people and me. I think it's O.K. to go in.
I also changed ah_calibration to ah_iq_cal_needed to make more sense.
v2 Use a workqueue instead of a tasklet for calibration
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No functional changes, just a few comments/documentation/cleanup
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add TXNOFRM to INT_TX_ALL since it's a TX interrupt too.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since card has 12 tx queues and we want to keep track of the interrupts
per queue we can't fit all these interrupt bits on a single register.
So we have 5 registers, the primary interrupt status register (PISR) and
the 4 secondary interupt status registers (SISRs).
In order to be able to read them all at once (atomic operation) Atheros
introduced the Read-And-Clear registers to make things easier. So when
reading RAC_PISR register, hw does a read on PISR and all SISRs, returns
the value of PISR, copies all SISR values to their shadow copies (RAC_SISRx)
and clears PISR and SISRs. This saves us from reading PISR/SISRs in a sequence.
So far we 've used this approach and MadWiFi/Windows driver etc also used it
for years.
It turns out this operation is not atomic after all (at least not on all cards)
That means it's possible to loose some interrupts because they came after the
copy step and hw cleared them on the clean step !
That's probably the reason we got missed beacons, got stuck queues etc and
couldn't figure out what was going on.
With this patch we switch from RaC operation to an alternative method (that
makes more sense IMHO anyway, I just chose to be on the safe side so far).
Instead of reading RAC registers, we read the normal PISR/SISR registers and
clear any bits we got by writing them back on the register. This will clear only
the bits we got on our read step and leave any new bits unaffected (at least
that's what docs say). So if any new interrupts come up we won't miss it.
I've tested this with an AR5213 and an AR2425 and it seems O.K.
Many thanks to Adrian Chadd for debuging this and reviewing the patch !
v2: Make sure we don't clear PISR bits that map to SISR generated interrupts
(added a comment on the code for this)
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's little point in this config symbol, if
tracing is disabled the overhead is negligible
and if you think it's too bad you can always
turn off tracing completely.
Also remove the part where we don't have sparse
check the tracing code -- it seems that it can
now deal with it (or the code changed).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We used to initiate a path discovery when receiving a frame for which
there is no forwarding information. To cut down on PREQ spam, just send
a (gated) PERR in response.
Also separate path discovery logic from nexthop querying. This patch
means we no longer queue frames when forwarding, so kill the PERR TX
stuff in discard_frame().
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can't rely on ieee80211_select_queue() to do its job at this point
since the skb->protocol is not yet known. Instead, factor out and reuse
the queue mapping logic for injected frames.
Also, to mitigate congestion, forwarded frames should be dropped if the
outgoing queue was stopped. This was not correctly implemented as we
were not checking the right queue. Furthermore, we were dropping frames
that had arrived to their destination if that queue was stopped.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
HWMP originator and target addresses were switched on the air but also
on reception, which is why path selection still worked.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't write the TA until next hop is actually known, since we might need
the original TA for sending a PERR. Previously we would send a PERR to
ourself if path resolution for a forwarded frame failed.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register(),
so we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Dan Williams <dcbw@redhat.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Luciano Coelho <coelho@ti.com>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It doesn't have any actual effect here, but we should
skb_put() *before* copying the data.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Emmanuel reported that my previous patches to enable
handing all fragments to drivers at once triggered
the warning that the SKB queue wasn't empty. This is
happening when we actually queue up some frames and
don't hand them to the driver (queues are stopped).
The reason for it is that my code that splices the
frame(s) over to the pending queue didn't re-init
the local queue, so skb_queue_empty() was false. Fix
this by using the _init versions of the splicing.
Also, convert the warning to WARN_ON_ONCE.
Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously BlockAcks were always dropped by the rt2800 hardware while
BlockAckReqs were always accepted. However, both are only useful on
monitor interfaces at the moment and both are control frames. So
pass them up when mac80211 sets FIF_CONTROL.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The recent discussion regarding an incorrect return of IRQ_HANDLED
from rt2800pci caused me to look at this PCI interrupt routine. I
discovered that changes were needed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
