summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-12-18perf dso: Export data_file_size() method there are no symbolsAdrian Hunter
Will be used outside dso.c in a followup patch, so rename it and make it non-static. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20181127084634.12469-1-adrian.hunter@intel.com [ split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2018-12-18KVM: arm/arm64: vgic: Cap SPIs to the VM-defined maximumMarc Zyngier
SPIs should be checked against the VMs specific configuration, and not the architectural maximum. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Clarify explanation of STAGE2_PGTABLE_LEVELSChristoffer Dall
In attempting to re-construct the logic for our stage 2 page table layout I found the reasoning in the comment explaining how we calculate the number of levels used for stage 2 page tables a bit backwards. This commit attempts to clarify the comment, to make it slightly easier to read without having the Arm ARM open on the right page. While we're at it, fixup a typo in a comment that was recently changed. Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: vgic: Do not cond_resched_lock() with IRQs disabledJulien Thierry
To change the active state of an MMIO, halt is requested for all vcpus of the affected guest before modifying the IRQ state. This is done by calling cond_resched_lock() in vgic_mmio_change_active(). However interrupts are disabled at this point and we cannot reschedule a vcpu. We actually don't need any of this, as kvm_arm_halt_guest ensures that all the other vcpus are out of the guest. Let's just drop that useless code. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Suggested-by: Christoffer Dall <christoffer.dall@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Add support for creating PUD hugepages at stage 2Punit Agrawal
KVM only supports PMD hugepages at stage 2. Now that the various page handling routines are updated, extend the stage 2 fault handling to map in PUD hugepages. Addition of PUD hugepage support enables additional page sizes (e.g., 1G with 4K granule) which can be useful on cores that support mapping larger block sizes in the TLB entries. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [ Replace BUG() => WARN_ON(1) for arm32 PUD helpers ] Signed-off-by: Suzuki Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Update age handlers to support PUD hugepagesPunit Agrawal
In preparation for creating larger hugepages at Stage 2, add support to the age handling notifiers for PUD hugepages when encountered. Provide trivial helpers for arm32 to allow sharing code. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [ Replaced BUG() => WARN_ON(1) for arm32 PUD helpers ] Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Support handling access faults for PUD hugepagesPunit Agrawal
In preparation for creating larger hugepages at Stage 2, extend the access fault handling at Stage 2 to support PUD hugepages when encountered. Provide trivial helpers for arm32 to allow sharing of code. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [ Replaced BUG() => WARN_ON(1) in PUD helpers ] Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Support PUD hugepage in stage2_is_exec()Punit Agrawal
In preparation for creating PUD hugepages at stage 2, add support for detecting execute permissions on PUD page table entries. Faults due to lack of execute permissions on page table entries is used to perform i-cache invalidation on first execute. Provide trivial implementations of arm32 helpers to allow sharing of code. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [ Replaced BUG() => WARN_ON(1) in arm32 PUD helpers ] Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm64: Support dirty page tracking for PUD hugepagesPunit Agrawal
In preparation for creating PUD hugepages at stage 2, add support for write protecting PUD hugepages when they are encountered. Write protecting guest tables is used to track dirty pages when migrating VMs. Also, provide trivial implementations of required kvm_s2pud_* helpers to allow sharing of code with arm32. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> [ Replaced BUG() => WARN_ON() in arm32 pud helpers ] Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: Introduce helpers to manipulate page table entriesPunit Agrawal
Introduce helpers to abstract architectural handling of the conversion of pfn to page table entries and marking a PMD page table entry as a block entry. The helpers are introduced in preparation for supporting PUD hugepages at stage 2 - which are supported on arm64 but do not exist on arm. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on faultPunit Agrawal
Stage 2 fault handler marks a page as executable if it is handling an execution fault or if it was a permission fault in which case the executable bit needs to be preserved. The logic to decide if the page should be marked executable is duplicated for PMD and PTE entries. To avoid creating another copy when support for PUD hugepages is introduced refactor the code to share the checks needed to mark a page table entry as executable. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: Share common code in user_mem_abort()Punit Agrawal
The code for operations such as marking the pfn as dirty, and dcache/icache maintenance during stage 2 fault handling is duplicated between normal pages and PMD hugepages. Instead of creating another copy of the operations when we introduce PUD hugepages, let's share them across the different pagesizes. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: vgic-v2: Set active_source to 0 when restoring stateChristoffer Dall
When restoring the active state from userspace, we don't know which CPU was the source for the active state, and this is not architecturally exposed in any of the register state. Set the active_source to 0 in this case. In the future, we can expand on this and exposse the information as additional information to userspace for GICv2 if anyone cares. Cc: stable@vger.kernel.org Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: Log PSTATE for unhandled sysregsMark Rutland
When KVM traps an unhandled sysreg/coproc access from a guest, it logs the guest PC. To aid debugging, it would be helpful to know which exception level the trap came from, along with other PSTATE/CPSR bits, so let's log the PSTATE/CPSR too. Acked-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18KVM: arm/arm64: Fix VMID alloc race by reverting to lock-lessChristoffer Dall
We recently addressed a VMID generation race by introducing a read/write lock around accesses and updates to the vmid generation values. However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but does so without taking the read lock. As far as I can tell, this can lead to the same kind of race: VM 0, VCPU 0 VM 0, VCPU 1 ------------ ------------ update_vttbr (vmid 254) update_vttbr (vmid 1) // roll over read_lock(kvm_vmid_lock); force_vm_exit() local_irq_disable need_new_vmid_gen == false //because vmid gen matches enter_guest (vmid 254) kvm_arch.vttbr = <PGD>:<VMID 1> read_unlock(kvm_vmid_lock); enter_guest (vmid 1) Which results in running two VCPUs in the same VM with different VMIDs and (even worse) other VCPUs from other VMs could now allocate clashing VMID 254 from the new generation as long as VCPU 0 is not exiting. Attempt to solve this by making sure vttbr is updated before another CPU can observe the updated VMID generation. Cc: stable@vger.kernel.org Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race" Reviewed-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18arm64: KVM: Consistently advance singlestep when emulating instructionsMark Rutland
When we emulate a guest instruction, we don't advance the hardware singlestep state machine, and thus the guest will receive a software step exception after a next instruction which is not emulated by the host. We bodge around this in an ad-hoc fashion. Sometimes we explicitly check whether userspace requested a single step, and fake a debug exception from within the kernel. Other times, we advance the HW singlestep state rely on the HW to generate the exception for us. Thus, the observed step behaviour differs for host and guest. Let's make this simpler and consistent by always advancing the HW singlestep state machine when we skip an instruction. Thus we can rely on the hardware to generate the singlestep exception for us, and never need to explicitly check for an active-pending step, nor do we need to fake a debug exception from the guest. Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18arm64: KVM: Skip MMIO insn after emulationMark Rutland
When we emulate an MMIO instruction, we advance the CPU state within decode_hsr(), before emulating the instruction effects. Having this logic in decode_hsr() is opaque, and advancing the state before emulation is problematic. It gets in the way of applying consistent single-step logic, and it prevents us from being able to fail an MMIO instruction with a synchronous exception. Clean this up by only advancing the CPU state *after* the effects of the instruction are emulated. Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18irqchip: Add driver for Cirrus Logic Madera codecsRichard Fitzgerald
The Cirrus Logic Madera codecs (Cirrus Logic CS47L35/85/90/91 and WM1840) are highly complex devices containing up to 7 programmable DSPs and many other internal sources of interrupts plus a number of GPIOs that can be used as interrupt inputs. The large number (>150) of internal interrupt sources are managed by an on-board interrupt controller. This driver provides the handling for the interrupt controller. As the codec is accessed via regmap, we can make use of the generic IRQ functionality from regmap to do most of the work. Only around half of the possible interrupt source are currently of interest from the driver so only this subset is defined. Others can be added in future if needed. The KConfig options are not user-configurable because this driver is mandatory so is automatically included when the parent MFD driver is selected. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18Merge tag 'asoc-v4.21' of ↵Takashi Iwai
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v4.21 Not much work on the core this time around but we've seen quite a bit of driver work, including on the generic DT drivers. There's also a large part of the diff from a merge of the DaVinci and OMAP directories, along with some active development there: - Preparatory work from Morimoto-san for merging the audio-graph and audio-graph-scu cards. - A merge of the TI OMAP and DaVinci directories, the OMAP product line has been merged into the DaVinci product line so there is now a lot of IP sharing which meant that the split directories just got in the way. This has pulled in a few architecture changes as well. - A big cleanup of the Maxim MAX9867 driver from Ladislav Michl. - Support for Asahi Kaesi AKM4118, AMD ACP3x, Intel platforms with RT5660, Meson AXG S/PDIF inputs, several Qualcomm IPs and Xilinx I2S controllers.
2018-12-18Merge branch 'bpf-bpftool-mount-tracefs'Daniel Borkmann
Quentin Monnet says: ==================== This series focus on mounting (or not mounting) tracefs with bpftool. First patch makes bpftool attempt to mount tracefs if tracefs is not found when running "bpftool prog tracelog". Second patch adds an option to bpftool to prevent it from attempting to mount any file system (tracefs or bpffs), in case this behaviour is undesirable for some users. ==================== Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18tools: bpftool: add an option to prevent auto-mount of bpffs, tracefsQuentin Monnet
In order to make life easier for users, bpftool automatically attempts to mount the BPF virtual file system, if it is not mounted already, before trying to pin objects in it. Similarly, it attempts to mount tracefs if necessary before trying to dump the trace pipe to the console. While mounting file systems on-the-fly can improve user experience, some administrators might prefer to avoid that. Let's add an option to block these mount attempts. Note that it does not prevent automatic mounting of tracefs by debugfs for the "bpftool prog tracelog" command. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18tools: bpftool: attempt to mount tracefs if required for tracelog cmdQuentin Monnet
As a follow-up to commit 30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe"), attempt to mount the tracefs virtual file system if it is not detected on the system before trying to dump content of the tracing pipe on an invocation of "bpftool prog tracelog". Usually, tracefs in automatically mounted by debugfs when the user tries to access it (e.g. "ls /sys/kernel/debug/tracing" mounts the tracefs). So if we failed to find it, it is probably that debugfs is not here either. Therefore, we just attempt a single mount, at a location that does not involve debugfs: /sys/kernel/tracing. Suggested-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18tools/bpf: check precise {func, line, jited_line}_info_rec_size in test_btfYonghong Song
Current btf func_info, line_info and jited_line are designed to be extensible. The record sizes for {func,line}_info are passed to kernel, and the record sizes for {func,line,jited_line}_info are returned to userspace during bpf_prog_info query. In bpf selftests test_btf.c, when testing whether kernel returns a legitimate {func,line, jited_line)_info rec_size, the test only compares to the minimum allowed size. If the returned rec_size is smaller than the minimum allowed size, it is considered incorrect. The minimum allowed size for these three info sizes are equal to current value of sizeof(struct bpf_func_info), sizeof(struct bpf_line_info) and sizeof(__u64). The original thinking was that in the future when rec_size is increased in kernel, the same test should run correctly. But this sacrificed the precision of testing under the very kernel the test is shipped with, and bpf selftest is typically run with the same repo kernel. So this patch changed the testing of rec_size such that the kernel returned value should be equal to the size defined by tools uapi header bpf.h which syncs with kernel uapi header. Martin discovered a bug in one of rec_size comparisons. Instead of comparing to minimum func_info rec_size 8, it compares to 4. This patch fixed that issue as well. Fixes: 999d82cbc044 ("tools/bpf: enhance test_btf file testing to test func info") Fixes: 05687352c600 ("bpf: Refactor and bug fix in test_func_type in test_btf.c") Fixes: 4d6304c76355 ("bpf: Add unit tests for bpf_line_info") Suggested-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-12-18Merge tag 'perf-core-for-mingo-4.21-20181217' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Introduce 'perf record --aio' to use asynchronous IO trace writing, disabled by default (Alexey Budankov) - Add fallback routines to be used in places where we don't have the CPU mode (kernel/userspace/hypervisor) and thus must first fallback lookups looking at all map trees when trying to resolve symbols (Adrian Hunter) - Fix error with config term "pt=0", where we should just force "pt=1" and warn the user about the former being nonsensical (Adrian Hunter) - Fix 'perf test' entry where we expect 'sleep' to come in a PERF_RECORD_COMM but instead we get 'coreutils' when sleep is provided by some versions of the 'coreutils' package (Adrian Hunter) - Introduce 'perf top --kallsyms file' to match 'perf report --kallsyms', useful when dealing with BPF, where symbol resolution happens via kallsyms, not via the default vmlinux ELF symtabs (Arnaldo Carvalho de Melo) - Support 'srccode' output field in 'perf script' (Andi Kleen) - Introduce basic 'perf annotation' support for the ARC architecture (Eugeniy Paltsev) - Compute and display average IPC and IPC coverage per symbol in 'perf annotate' and 'perf report' (Jin Yao) - Make 'perf top' use ordered_events and process histograms in a separate thread (Jiri Olsa) - Make 'perf trace' use ordered_events (Jiri Olsa) - Add support for ETMv3 and PTMv1.1 decoding in cs-etm (Mathieu Poirier) - Support for ARM A32/T32 instruction sets in CoreSight trace (cs-etm) (Robert Walker) - Fix 'perf stat' shadow stats for clock events. (Ravi Bangoria) - Remove needless rb_tree extra indirection from map__find() (Eric Saint-Etienne) - Fix CSV mode column output for non-cgroup events in 'perf stat' (Stephane Eranian) - Add sanity check to libtraceevent's is_timestamp_in_us() (Tzvetomir Stoyanov) - Use ERR_CAST instead of ERR_PTR(PTR_ERR()) (Wen Yang) - Fix Load_Miss_Real_Latency on SKL/SKX intel vendor event files (Andi Kleen) - strncpy() fixes triggered by new warnings on gcc 8.2.0 (Arnaldo Carvalho de Melo) - Handle tracefs syscall tracepoint older 'nr' field in 'perf trace', that got renamed to '__syscall_nr' to work in older kernels (Arnaldo Carvalho de Melo) - Give better hint about devel package for libssl (Arnaldo Carvalho de Melo) - Fix the 'perf trace' build in architectures lacking explicit mmap.h file (Arnaldo Carvalho de Melo) - Remove extra rb_tree traversal indirection from map__find() (Eric Saint-Etienne) - Disable breakpoint tests for 32-bit ARM (Florian Fainelli) - Fix typos all over the place, mostly in comments, but also in some debug messages and JSON files (Ingo Molnar) - Allow specifying proc-map-timeout in config file (Mark Drayton) - Fix mmap_flags table generation script (Sihyeon Jang) - Fix 'size' parameter to snprintf in the 'perf config' code (Sihyeon Jang) - More libtraceevent renames to make it a proper library (Tzvetomir Stoyanov) - Implement new API tep_get_ref() in libtraceevent (Tzvetomir Stoyanov) - Added support for pkg-config in libtraceevent (Tzvetomir Stoyanov) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-18x86/fsgsbase/64: Fix the base write helper functionsChang S. Bae
Andy spotted a regression in the fs/gs base helpers after the patch series was committed. The helper functions which write fs/gs base are not just writing the base, they are also changing the index. That's wrong and needs to be separated because writing the base has not to modify the index. While the regression is not causing any harm right now because the only caller depends on that behaviour, it's a guarantee for subtle breakage down the road. Make the index explicitly changed from the caller, instead of including the code in the helpers. Subsequently, the task write helpers do not handle for the current task anymore. The range check for a base value is also factored out, to minimize code redundancy from the caller. Fixes: b1378a561fd1 ("x86/fsgsbase/64: Introduce FS/GS base helper functions") Suggested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andy Lutomirski <luto@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://lkml.kernel.org/r/20181126195524.32179-1-chang.seok.bae@intel.com
2018-12-18genirq: Fix various typos in commentsIngo Molnar
Go over the IRQ subsystem source code (including irqchip drivers) and fix common typos in comments. No change in functionality intended. Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-kernel@vger.kernel.org
2018-12-18mac80211: do not advertise HE cap IE if HE disabledShaul Triebitz
When disabling HE due to the lack of HT/VHT, do it at an earlier stage to avoid advertising HE capabilities IE. Also, at this point, no need to check if AP supports HE, since it is already checked earlier (in ieee80211_prep_channel). Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18mac80211: set STA flag DISABLE_HE if HE is not supportedShaul Triebitz
Up until now, the IEEE80211_STA_DISABLE_HE flag was set only based on whether the AP has advertised HE capabilities. This flag should be set also if STA does not support HE (regardless of the AP support). Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18mac80211: update driver when MU EDCA params changeShaul Triebitz
Similar to WMM IE, if MU_EDCA IE parameters changed (or ceased to exist) tell the Driver about it. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18mac80211: update HE operation fields to D3.0Shaul Triebitz
HE Operation element has changed in 11ax D3.0. Update the fields accordingly. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18mac80211: propagate the support for TWT to the driverEmmanuel Grumbach
TWT is a feature that was added in 11ah and enhanced in 11ax. There are two bits that need to be set if we want to use the feature in 11ax: one in the HE Capability IE and one in the Extended Capability IE. This is because of backward compatibility between 11ah and 11ax. In order to simplify the flow for the low level driver in managed mode, aggregate the two bits and add a boolean that tells whether TWT is supported or not, but only if 11ax is supported. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18ieee80211: add bits for TWT in Extended Capabilities IEEmmanuel Grumbach
These bits are defined in ieee802.11ax to advertise support for TWT in addition to the bits in the HE IE. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18x86/speculation: Add support for STIBP always-on preferred modeThomas Lendacky
Different AMD processors may have different implementations of STIBP. When STIBP is conditionally enabled, some implementations would benefit from having STIBP always on instead of toggling the STIBP bit through MSR writes. This preference is advertised through a CPUID feature bit. When conditional STIBP support is requested at boot and the CPU advertises STIBP always-on mode as preferred, switch to STIBP "on" support. To show that this transition has occurred, create a new spectre_v2_user_mitigation value and a new spectre_v2_user_strings message. The new mitigation value is used in spectre_v2_user_select_mitigation() to print the new mitigation message as well as to return a new string from stibp_state(). Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Borislav Petkov <bp@alien8.de> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/20181213230352.6937.74943.stgit@tlendack-t1.amdoffice.net
2018-12-18nl80211: Add support to notify radar event info received from STASriram R
Currently radar detection and corresponding channel switch is handled at the AP device. STA ignores these detected radar events since the radar signal can be seen mostly by the AP as well. But in scenarios where a radar signal is seen only at STA, notifying this event to the AP which can trigger a channel switch can be useful. Stations can report such radar events autonomously through Spectrum management (Measurement Report) action frame to its AP. The userspace on processing the report can notify the kernel with the use of the added NL80211_CMD_NOTIFY_RADAR to indicate the detected event and inturn adding the reported channel to NOL. Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18irqchip/irq-imx-gpcv2: Add IRQCHIP_DECLARE for i.MX8MQ compatibleLucas Stach
The GPC node on i.MX8MQ can not claim to be compatible with the i.MX7D GPC, as the power gating part has some significant differences. Thus we can not rely on the irqchip being probed with the old compatible. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18irqchip/irq-rda-intc: Fix return value check in rda8810_intc_init()Wei Yongjun
In case of error, the function of_io_request_and_map() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: d852e62ad689 ("irqchip: Add RDA8810PL interrupt driver") Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-12-18x86/topology: Use total_cpus for max logical packages calculationHui Wang
nr_cpu_ids can be limited on the command line via nr_cpus=. This can break the logical package management because it results in a smaller number of packages while in kdump kernel. Check below case: There is a two sockets system, each socket has 8 cores, which has 16 logical cpus while HT was turn on. 0 1 2 3 4 5 6 7 | 16 17 18 19 20 21 22 23 cores on socket 0 threads on socket 0 8 9 10 11 12 13 14 15 | 24 25 26 27 28 29 30 31 cores on socket 1 threads on socket 1 While starting the kdump kernel with command line option nr_cpus=16 panic was triggered on one of the cpus 24-31 eg. 26, then online cpu will be 1-15, 26(cpu 0 was disabled in kdump), ncpus will be 16 and __max_logical_packages will be 1, but actually two packages were booted on. This issue can reproduced by set kdump option nr_cpus=<real physical core numbers>, and then trigger panic on last socket's thread, for example: taskset -c 26 echo c > /proc/sysrq-trigger Use total_cpus which will not be limited by nr_cpus command line to calculate the value of __max_logical_packages. Signed-off-by: Hui Wang <john.wanghui@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: <guijianfeng@huawei.com> Cc: <wencongyang2@huawei.com> Cc: <douliyang1@huawei.com> Cc: <qiaonuohan@huawei.com> Link: https://lkml.kernel.org/r/20181107023643.22174-1-john.wanghui@huawei.com
2018-12-18Merge branch 'asoc-4.21' into asoc-nextMark Brown
2018-12-18Merge branch 'asoc-4.20' into asoc-linusMark Brown
2018-12-18ASoC: ti: Kconfig: Remove the deprecated optionsPeter Ujfalusi
We no longer have these options used anywhere. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: davinci_all_defconfig: Update the audio optionsPeter Ujfalusi
Use the new options for default audio support. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: omap1_defconfig: Do not select ASoC by defaultPeter Ujfalusi
No audio support is enabled by default via ASoC, disable the code as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: omap2plus_defconfig: Update the audio optionsPeter Ujfalusi
Use the new options for default audio support and enable Nokia n900 audio as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: davinci: dm365-evm: Update for the new ASoC Kcofnig optionsPeter Ujfalusi
The codec selection config options for DMA365 has been changed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: OMAP2: Update for new MCBSP Kconfig optionPeter Ujfalusi
The MCBSP config option has been changed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ARM: OMAP1: Makefile: Update for new MCBSP Kconfig optionPeter Ujfalusi
The MCBSP config option has been changed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18MAINTAINERS: Add entry for sound/soc/ti and update the OMAP audio supportPeter Ujfalusi
The sound/soc/davinci and omap directories are merged under sound/soc/ti. Add myself as maintainer and update the OMAP audio support section with the new path and file names. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18ASoC: ti: Merge davinci and omap directoriesPeter Ujfalusi
Create new directory to contain all Texas Instruments specific DAI, platform and machine drivers instead of scattering them under davinci and omap directories. There is already inter dependency between the two directories becasue of McASP (on dra7x it is serviced by sDMA, not EDMA). With the upcoming AM654 we will need to introduce new platform driver for UDMA and it does not fit under davinci, nor under omap. With the move I have restructured the Kconfig to be more usable in the era of simple-sound-card: CPU DAIs can be selected individually and they will select the platform driver they can be served with. To avoid breakage, I have moved over deprecated Kconfig options so defconfig builds will work without regression. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> For sound/soc/{omap => ti}: Tested-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-18mac80211: don't build AMSDU from GSO packetsSara Sharon
If we build AMSDU from GSO packets, it can lead to bad results if anyone tries to call skb_gso_segment on the packets. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-12-18mac80211: document RCU requirements for ieee80211_tx_dequeue()Johannes Berg
In the iwlwifi conversion, we sometimes call this from outside of the wake_tx_queue() method, and in those cases must be in an RCU critical section. Document this requirement. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>