The python binding still doesn't provide symbol resolving facilities,
but the recent addition of the trace_event__register_resolver() function
made it add as a dependency the machine__resolve_kernel_addr() method,
that in turn drags all the symbol resolving code.
The problem:
[root@zoo ~]# perf test -v python
17: Try 'import perf' in python, checking link problems :
--- start ---
test child forked, pid 6853
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /tmp/build/perf/python/perf.so: undefined symbol: machine__resolve_kernel_addr
test child finished with -1
---- end ----
Try 'import perf' in python, checking link problems: FAILED!
[root@zoo ~]#
Fix it by requiring this function to receive the resolver as a
parameter, just like pevent_register_function_resolver(), i.e. do
not explicitely refer to an object file not included in
tools/perf/util/python-ext-sources.
[root@zoo ~]# perf test python
17: Try 'import perf' in python, checking link problems : Ok
[root@zoo ~]#
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Fixes: c3168b0db9 ("perf symbols: Provide libtraceevent callback to resolve kernel symbols")
Link: http://lkml.kernel.org/n/tip-vxlhh95v2em9zdbgj3jm7xi5@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Calling spfi_wait_all_done is not required if the transfer has timed
out before all data is transferred.
spfi_wait_all_done polls for Alldone interrupt which is triggered to
mark the transfer as complete and to indicate it is now safe to issue
a new transfer.
Fixes: 8c2c8c0 ("spi: img-spfi: Control CS lines with GPIO")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Restart the tick when necessary from the irq exit path. It makes nohz
full more flexible, simplify the related IPIs and doesn't bring
significant overhead on irq exit.
In a longer term view, it will allow us to piggyback the nohz kick
on the scheduler IPI in the future instead of sending a dedicated IPI
that often doubles the scheduler IPI on task wakeup. This will require
more changes though including careful review of resched_curr() callers
to include nohz full needs.
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
On nohz full early days, idle dynticks and full dynticks weren't well
integrated and we couldn't risk full dynticks calls on idle without
risking messing up tick idle statistics. This is why we prevented such
thing to happen.
Nowadays full dynticks and idle dynticks are better integrated and
interact without known issue.
So lets remove that.
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Normally the tilegx networking shim sends irqs to all the cores
to distribute the load of processing incoming-packet interrupts,
so that you can get to multiple Gb's of traffic inbound.
However, in nohz_full mode we don't want to interrupt the
nohz_full cores by default, so we limit the set of cores we use
to only the online housekeeping cores.
To make client code easier to read, we introduce a new nohz_full
accessor, housekeeping_cpumask(), which returns a pointer to the
housekeeping_mask if nohz_full is enabled, and otherwise returns
the cpu_possible_mask.
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
That code wrongly assumes that cputime_t wraps jiffies_t. Lets use
the correct accessors/mutators.
In practice there should be no harm yet because alpha currently
only support tick based cputime accounting which is always jiffies
based.
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc; John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
That code wrongly assumes that cputime_t wraps jiffies_t. Lets use
the correct accessors/mutators.
No real harm now as that code can't be used with full dynticks.
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc; John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
HZ never goes much further 1000 and a bit. And if we ever reach one tick
per microsecond, we might be having a problem.
Lets stop maintaining this special case, just leave a paranoid check.
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc; John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
* pm-cpufreq:
cpufreq: Avoid attempts to create duplicate symbolic links
intel_pstate: Add get_scaling cpu_defaults param to Knights Landing
* acpi-pm:
ACPI / PM: Use target_state to set the device power state
Add helper iterator macros for iterating over the source and sink paths of
widget. This will make it easier to change the implementation later on.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
When running dapm_dai_get_connected_widgets() currently in
is_connected_{input,output}_ep() for each widget that gets added the array
is resized and the code also loops over all existing entries to avoid
adding a widget multiple times.
The former can be avoided by collecting the widgets in a linked list and
only once we have all widgets allocate the array.
The later can be avoided by changing when the widget is added. Currently it
is added when walking the neighbor lists of a widget. Since a widget can be
neighbors with multiple other widgets it could get added twice and hence
the check is necessary. But the main body of is_connected_{input,output}_ep
is guaranteed to be only executed at most once per widget. So adding the
widget to the list at the beginning of the function automatically makes
sure that each widget gets only added once. The only difference is that
using this method the starting point itself will also end up on the list,
but it can easily be skipped when creating the array.
Overall this reduces the code size and speeds things slightly up.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
list_first_entry() always returns non NULL and since the code previously
checked that list is not empty it will also be a valid pointer. Furthermore
a path has always a sink or a source widget. So both checks are redundant
and can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
It's safe to call gpiod_set_value() with NULL desc.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If devm_gpiod_get_optional() return ERR_PTR, it means something wrong
so request gpio fails. We had better return error in such case.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no smp_rmb matching the smp_wmb. shared_msr_update is called from
hardware_enable, which in turn is called via on_each_cpu. on_each_cpu
and must imply a read memory barrier (on x86 the rmb is achieved simply
through asm volatile in native_apic_mem_write).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acer Aspire Switch 12 keyboard Chicony's controller reports too big usage
index on the 1st interface. The patch fixes the report. The work based on
solution from drivers/hid/hid-holtek-mouse.c
Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=101721
Signed-off-by: Nicholas Kudriavtsev <nkudriavtsev@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Since this wheel is now available, and the USBID is listed on their website,
this patch adds it to allow the hid-lg4ff force feedback driver to find it.
I do not have this wheel to test with, but this should at least get it working
in emulation mode.
Note: There is probably more work required for adjust HID descriptor and handle
switching between emulation and native modes.
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The limit should be ARRAY_SIZE(params) (5 elements) here instead of
sizeof(params) (20 bytes).
Fixes: 08177f40bd ('HID: uclogic: merge hid-huion driver in hid-uclogic')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
1. Rework logging infrastructure (s390dbf) to integrate feedback learned
when debugging performance and test issues
2. Some cleanups and simplifications for CMMA handling
3. Fix gdb debugging and single stepping on some instructions
4. Error handling for storage key setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAABAgAGBQJVuJbjAAoJEBF7vIC1phx8ky0QAImmDTvU4D1QNJyyHn6OZ1v8
DogjNTGpeGXxfq6aMPJDn7kkSo2hubZ57ZUsd70k1i/77EMNcjzjSTn82GAAQZPC
kBPHTMoOV0tp6J8/uTfadhYWQNzh+yqBP8L+4yHbyo8Ro/poLABeTBk9Ojcqjpb8
mdthZYvOzfsthd74Giva1ttqxrIYc9D1S2wzWUv/eFg6gpBg7TKJlt1DAltiP1x6
arfqB9rmX2yqYniXWVW2HrQK6VP3yC2hFGo5nbehlBtmY7wkQj8Ab5g7vtHtvmGX
BENAMgIew3IeJSbqxACFub8J6FhYndzo6X5CnrUweYq8DscW2u2DrJQLTuKie9xt
7V9nu2jqJ7emx0lnemXIdgc96cEyubh5Dy2ZmW1zqV2jM4I8O86NgsRgeBpc86ES
TOvErgaLOxEZwP6T89citQRcyZNPGlbiQVFAmNSvJpEcjo/ltd+/R2mEYjbm3JE4
hvF19Z6JQ1VaePqQZAuXNcQekiCK3ewNZER0ckc2PLJ9K/tLRl/R1Ymhgf82yXxh
ClTNgd+R+JQopxlRstNvZypEuJae2RPqPTlper3FLIu4k7Ugu3+Hg9FlEpj8kcI6
P8RO95sRBvdR7I6EMiNM/gBBOG5ocH5spG4xrc87AfyJQq+E3RK8DBpXQevK8Aio
gopinQ4eSlQwKF82v624
=rp6s
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-next-20150728' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-next
KVM: s390: Fixes and features for kvm/next (4.3)
1. Rework logging infrastructure (s390dbf) to integrate feedback learned
when debugging performance and test issues
2. Some cleanups and simplifications for CMMA handling
3. Fix gdb debugging and single stepping on some instructions
4. Error handling for storage key setup
Depending on user space, some capabilities and vm attributes are
enabled at runtime. Let's log those events and while we're at it,
log querying the vm attributes as well.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
In addition to the per VM debug logs, let's provide a global
one for KVM-wide events, like new guests or fatal errors.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Use the default log level 3 for state changing and/or seldom events,
use 4 for others. Also change some numbers from %x to %d and vice versa
to match documentation. If hex, let's prepend the numbers with 0x.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
We do not use the exception logger, so the 2nd area is unused.
Just have one area that is bigger (32 pages).
At the same time we can limit the debug feature size to 7
longs, as the largest user has 3 parameters + string + boiler
plate (vCPU, PSW mask, PSW addr)
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
The old Documentation/s390/kvm.txt file is either
outdated or described in Documentation/virtual/kvm/api.txt.
Let's get rid of it.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
This patch adds names for missing irq types to the trace events.
In order to identify adapter irqs, the define is moved from
interrupt.c to the other basic irq defines in uapi/linux/kvm.h.
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This reworks the debug logging for interrupt related logs.
Several changes:
- unify program int/irq
- improve decoding (e.g. use mcic instead of parm64 for machine
check injection)
- remove useless interrupt type number (the name is enough)
- rename "interrupt:" to "deliver:" as the other side is called "inject"
- use log level 3 for state changing and/or seldom events (like machine
checks, restart..)
- use log level 4 for frequent events
- use 0x prefix for hex numbers
- add pfault done logging
- move some tracing outside spinlock
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
We're not only interested in the address of the control block, but
also in the requested subcommand and for the token subcommand, in the
specified token address and masks.
Suggested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
The "from user"/"from kernel" part of the log/trace messages is not
always correct anymore and therefore not really helpful.
Let's remove that part from the log + trace messages. For program
interrupts, we can now move the logging/tracing part into the real
injection function, as already done for the other injection functions.
Reviewed-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
SPX (SET PREFIX) and SIGP (Set prefix) can change the prefix
register of a CPU. As sigp set prefix may be handled in user
space (KVM_CAP_S390_USER_SIGP), we would not log the changes
triggered via SIGP in that case. Let's have just one VCPU_EVENT
at the central location that tracks prefix changes.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Let's add a vcpu event for the page reference handling and change
the default debugging level for the ipl diagnose. Both are not
frequent AND change the global state, so lets log them always.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Sometimes kvm stat counters are the only performance metric to check
after something went wrong. Let's add additional counters for some
diagnoses.
In addition do the count for diag 10 all the time, even if we inject
a program interrupt.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
There is no point in resetting the CMMA state if it was never enabled.
Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
As we already only enable CMMA when userspace requests it, we can
safely move the additional checks to the request handler and avoid
doing them multiple times. This also tells userspace if CMMA is
available.
Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This patch fixes NULL pointer error by removing the unneeded kfree() call
of edev->name because extcon-palmas no longer allocate the memory for edev->name.
Fixes: d71aadda19 ("extcon: Remove the optional name of extcon device")
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
When guest debugging is active, space-switch events might be enforced
by PER. While the PER events are correctly filtered out,
space-switch-events could be forwarded to the guest, although from a
guest point of view, they should not have been reported.
Therefore we have to filter out space-switch events being concurrently
reported with a PER event, if the PER event got filtered out. To do so,
we theoretically have to know which instruction was responsible for the
event. As the applicable instructions modify the PSW address, the
address space set in the PSW and even the address space in cr1, we
can't figure out the instruction that way.
For this reason, we have to rely on the information about the old and
new address space, in order to guess the responsible instruction type
and do appropriate checks for space-switch events.
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
As enabling storage keys might fail, we should forward the error.
Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
As we may like to use a bisection search on the tables in future, we
need them to be ordered. For convenience we expect the compiled tables
to be order and check on initialisation. However, the validator used the
wrong iterators failed to spot the misordered MI tables and instead
walked off into the unknown (as spotted by kasan).
Signed-off-by: Hanno Boeck <hanno@hboeck.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Again hand-assemble patch ...]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In the future, we may want to speed up command/register searching using
a bisection and so we require them to be in ascending order respectively
by command value or register address. However, this was not true for one
pair in the MI table; make it so.
Signed-off-by: Hanno Boeck <hanno@hboeck.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Hand-assemble patch from raw patch from Hanno and commit message from Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This patch enables raw Rx/Tx encap mode to support software based
crypto engine. This patch introduces a new module param 'cryptmode'.
cryptmode:
0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
encapsulation to the firmware. This is the default mode.
1: Use sofware crypto engine globally with raw mode TX/RX
encapsulation to the firmware.
Known limitation:
A-MSDU must be disabled for RAW Tx encap mode to perform well when
heavy traffic is applied.
Testing: (by Michal Kazior <michal.kazior@tieto.com>)
a) Performance Testing
cryptmode=1
ap=qca988x sta=killer1525
killer1525 -> qca988x 194.496 mbps [tcp1 ip4]
killer1525 -> qca988x 238.309 mbps [tcp5 ip4]
killer1525 -> qca988x 266.958 mbps [udp1 ip4]
killer1525 -> qca988x 477.468 mbps [udp5 ip4]
qca988x -> killer1525 301.378 mbps [tcp1 ip4]
qca988x -> killer1525 297.949 mbps [tcp5 ip4]
qca988x -> killer1525 331.351 mbps [udp1 ip4]
qca988x -> killer1525 371.528 mbps [udp5 ip4]
ap=killer1525 sta=qca988x
qca988x -> killer1525 331.447 mbps [tcp1 ip4]
qca988x -> killer1525 328.783 mbps [tcp5 ip4]
qca988x -> killer1525 375.309 mbps [udp1 ip4]
qca988x -> killer1525 403.379 mbps [udp5 ip4]
killer1525 -> qca988x 203.689 mbps [tcp1 ip4]
killer1525 -> qca988x 222.339 mbps [tcp5 ip4]
killer1525 -> qca988x 264.199 mbps [udp1 ip4]
killer1525 -> qca988x 479.371 mbps [udp5 ip4]
Note:
- only open network tested for RAW vs nwifi performance comparison
- killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
- used iperf
- OTA, devices a few cm apart from each other, no shielding
- tcpX/udpX, X - means number of threads used
Overview:
- relative Tx performance drop is seen but is within reasonable and
expected threshold (A-MSDU must be disabled with RAW Tx)
b) Connectivity Testing
cryptmode=1
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK
ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK
ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK
ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK
Note:
- each test takes all possible endpoint pairs and pings
- each pair-ping flushes arp table
- ip6 is used
c) Testbed Topology:
1ap1sta:
[ap] ---- [sta]
endpoints: ap, sta
1ap1sta2br:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]
endpoints: veth0, veth2, br0, br1
note: STA works in 4addr mode, AP has wds_sta=1
1ap1sta2br1vlan:
[veth0] [ap] ---- [sta] [veth2]
| | | |
[veth1] | \ [veth3]
\ / \ /
[br0] [br1]
| |
[vlan0_id2] [vlan1_id2]
endpoints: vlan0_id2, vlan1_id2
note: STA works in 4addr mode, AP has wds_sta=1
Credits:
Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
amsdu issue, contributed a workaround (already squashed into this
patch), and contributed the throughput and connectivity tests results.
Signed-off-by: David Liu <cfliu.tw@gmail.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Tested-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
During tx completion, tx_lock is held for longer than required, preventing
efficient refill of htt->pending_tx. Refactor the code so that only MSDU
related operations are protected by the lock.
Improves downstream performance on a dual-core ARM Freescale LS1024A
(f.k.a. Mindspeed Comcerto 2000) AP with a 3x3 client from 495 to 580 Mbps.
Other CPU bound multicore systems may also benefit.
Signed-off-by: Denton Gentry <dgentry@google.com>
Signed-off-by: Avery Pennarun <apenwarr@google.com>
[mfaltesek@google.com: removed conflicting code for tracking msdu_ids.]
Signed-off-by: Marty Faltesek <mfaltesek@google.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
If we got to the point where we are trying to stop sink CRC
the main output of this function was already gotten properly,
so don't return the error and let userspace use the crc data.
Let's replace the errnos returns with some log messages.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Right now if we face any kind of error sink crc calculation
stays enabled.
So, let's give a shot and try to stop it anyway if it got enabled.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When using DFS channels on Ath10k, kernel log has repeated warning message
'failed to process fft: -22' typically under medium/heavy traffic.
This patch switches the warnings to driver debug (WMI events) mode only
thus reducing log file noise.
DFS and spectral scan share underlying HW mechanisms and enabling one
(DFS) enables the other (spectral scan) as far as event reporting from
firmware to driver is concerned. Spectral scan events take no part in
processing of DFS radar pulses which are delivered as distinct events,
so the fft (spectral event) warning is harmless and DFS interference
detection/protection still occurs.
Symptoms seen & fix tested in both debug & non-debug modes on TP-Link
Archer C7 v2 platform.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Since we may conceivably encounter situations where the upper part of the
64bit register changes between reads, for example when a timestamp
counter overflows, change the WARN into a retry loop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes two misspellings of "distribution" in a comment.
Signed-off-by: Nik Nyby <nikolas@gnu.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This is a preparatory patch for moving irq_data struct members.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Chris Zankel <chris@zankel.net>
Link: http://lkml.kernel.org/r/20150713172018.264485572@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
