aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-03-27Merge tag 'sunxi-fixes-for-4.16' of ↵Arnd Bergmann2-5/+62
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes Pull "Allwinner Fixes for 4.16" from Maxime Ripard: The first and second patches fix the regulator support for the Bananapi M2 board. The last one updates my email address in MAINTAINERS. * tag 'sunxi-fixes-for-4.16' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: MAINTAINERS: update email address for Maxime Ripard ARM: dts: sun6i: a31s: bpi-m2: add missing regulators ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
2018-03-27Merge tag 'omap-for-v4.16/sram-fix-signed' of ↵Arnd Bergmann3-16/+38
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Pull "Two fixes for omap variants for v4.16-rc cycle" from Tony Lindgren: Fix insecure W+X mapping warning for SRAM for omaps that don't yet use drivers/misc/*sram*.c code. An earlier attempt at fixing this turned out to cause problems with PM on omap3, this version works with PM on omap3. Also fix dmtimer probe for omap16xx devices that was noticed with the pending dmtimer move to drivers. It seems this has been broken for a while and is a non-critical for booting. It is needed for PM on omap16xx though. * tag 'omap-for-v4.16/sram-fix-signed' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP: Fix SRAM W+X mapping ARM: OMAP: Fix dmtimer init for omap1
2018-03-27Merge tag 'tegra-for-4.17-misc' of ↵Arnd Bergmann1-1/+2
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux into fixes Pull "ARM: tegra: Miscellaneous changes for v4.17-rc1" from Thierry Reding: This contains a single patch to update the MAINTAINERS entry for the Tegra SMMU driver. * tag 'tegra-for-4.17-misc' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux: MAINTAINERS: Update Tegra IOMMU maintainer
2018-03-27x86/cpuid: Allow cpuid_read() to scheduleEric Dumazet1-8/+26
High latencies can be observed caused by a daemon periodically reading CPUID on all cpus. On KASAN enabled kernels ~10ms latencies can be observed. Even without KASAN, sending an IPI to a CPU, which is in a deep sleep state or in a long hard IRQ disabled section, waiting for the answer can consume hundreds of microseconds. cpuid_read() is invoked in preemptible context, so it can be converted to sleep instead of busy wait. Switching to smp_call_function_single_async() and a completion allows to reschedule and reduces CPU usage and latencies. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Eric Dumazet <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-03-27x86/msr: Allow rdmsr_safe_on_cpu() to scheduleEric Dumazet1-8/+24
High latencies can be observed caused by a daemon periodically reading various MSR on all cpus. On KASAN enabled kernels ~10ms latencies can be observed simply reading one MSR. Even without KASAN, sending an IPI to a CPU, which is in a deep sleep state or in a long hard IRQ disabled section, waiting for the answer can consume hundreds of microseconds. All usage sites are in preemptible context, convert rdmsr_safe_on_cpu() to use a completion instead of busy polling. Overall daemon cpu usage was reduced by 35 %, and latencies caused by msr_read() disappeared. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Eric Dumazet <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2018-03-27x86/mm: Update comment in detect_tme() regarding x86_phys_bitsKirill A. Shutemov1-5/+2
As Kai pointed out, the primary reason for adjusting x86_phys_bits is to reflect that the the address space is reduced and not the ability to communicate the available physical address space to virtual machines. Suggested-by: Kai Huang <[email protected]> Signed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Tom Lendacky <[email protected]> Cc: Dave Hansen <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2018-03-27x86/PCI: Fix a potential regression when using dmi_get_bios_year()Andy Shevchenko1-1/+3
dmi_get_bios_year() may return 0 when it cannot parse the BIOS date string. Previously this has been checked in pci_acpi_crs_quirks(). Update the code to restore old behaviour. Reported-by: Jean Delvare <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Lukas Wunner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rafael J . Wysocki <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 69c42d493db4 ("x86/pci: Simplify code by using the new dmi_get_bios_year() helper") Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27firmware/dmi_scan: Uninline dmi_get_bios_year() helperAndy Shevchenko2-9/+22
Uninline dmi_get_bios_year() which, in particular, allows us to optimize it in the future. While doing this, convert the function to return an error code when BIOS date is not present or not parsable, or CONFIG_DMI=n. Additionally, during the move, add a bit of documentation. Suggested-by: Bjorn Helgaas <[email protected]> Suggested-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Lukas Wunner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rafael J . Wysocki <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 492a1abd61e4 ("dmi: Introduce the dmi_get_bios_year() helper function") Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27drm/i915: Fix hibernation with ACPI S0 target stateImre Deak2-13/+11
After commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356 Author: Imre Deak <[email protected]> Date: Wed Aug 16 17:46:07 2017 +0300 drm/i915/gen9+: Set same power state before hibernation image save/restore during hibernation/suspend the power domain functionality got disabled, after which resume could leave it incorrectly disabled if the ACPI target state was S0 during suspend and i915 was not loaded by the loader kernel. This was caused by not considering if we resumed from hibernation as the condition for power domains reiniting. Fix this by simply tracking if we suspended power domains during system suspend and reinit power domains accordingly during resume. This will result in reiniting power domains always when resuming from hibernation, regardless of the platform and whether or not i915 is loaded by the loader kernel. The reason we didn't catch this earlier is that the enabled/disabled state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform and kernel config dependent: on my SKL the target state is S4 during PMSG_FREEZE and (with the driver loaded in the loader kernel) S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during PMSG_FREEZE but (contrary to this) power domains are not initialized during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or it's loaded but without the DMC firmware being available. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196 Reported-and-tested-by: [email protected] Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation image save/restore") Cc: [email protected] Cc: Ville Syrjälä <[email protected]> Cc: <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0f90603c33bdf6575cfdc81edd53f3f13ba166fb) Signed-off-by: Joonas Lahtinen <[email protected]>
2018-03-27drm/i915/execlists: Use a locked clear_bit() for synchronisation with interruptChris Wilson1-13/+8
We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old one). However, in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") those uncached reads were eliminated (on one path at least) and along with them our serialisation. The result is that we would very rarely miss notification of a new interrupt and leave a context-switch unprocessed, hanging the GPU. Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") Signed-off-by: Chris Wilson <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Reviewed-by: Michel Thierry <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 9153e6b7c85edbc89e874e5c83f86217c53dcfaf) Signed-off-by: Joonas Lahtinen <[email protected]>
2018-03-27drm/i915: Specify which engines to reset following semaphore/event lockupsChris Wilson1-2/+2
If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error handler to accept mask of hung engines") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Michel Thierry <[email protected]> Reviewed-by: Michel Thierry <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ca98317b89428e6ac17be0938b467ed78654dd56) Signed-off-by: Joonas Lahtinen <[email protected]>
2018-03-27drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.Dhinakaran Pandiyan1-5/+2
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reported-by: Laura Abbott <[email protected]> Cc: [email protected] Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by: Laura Abbott <[email protected]> Signed-off-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ad260ab32a4d94fa974f58262f8000472d34fd5b) Signed-off-by: Joonas Lahtinen <[email protected]>
2018-03-27x86/alternatives: Fixup alternative_call_2Alexey Dobriyan1-3/+1
The following pattern fails to compile while the same pattern with alternative_call() does: if (...) alternative_call_2(...); else alternative_call_2(...); as it expands into if (...) { }; <=== else { }; Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/20180114120504.GA11368@avx2
2018-03-27Merge tag 'drm-amdkfd-fixes-2018-03-25' of ↵Dave Airlie2-8/+15
git://people.freedesktop.org/~gabbayo/linux into drm-fixes - Programming VMID correctly for scratch memory with HWS - deallocating SDMA queues correctly in various situations * tag 'drm-amdkfd-fixes-2018-03-25' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Deallocate SDMA queues correctly drm/amdkfd: Fix scratch memory with HWS enabled
2018-03-27x86/mm/32: Remove unused node_memmap_size_bytes() & ↵David Rientjes4-42/+0
CONFIG_NEED_NODE_MEMMAP_SIZE logic node_memmap_size_bytes() has been unused since the v3.9 kernel, so remove it. Signed-off-by: David Rientjes <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Laura Abbott <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Fixes: f03574f2d5b2 ("x86-32, mm: Rip out x86_32 NUMA remapping code") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27Merge tag 'v4.16-rc7' into x86/mm, to fix up conflictIngo Molnar513-2799/+4867
Conflicts: arch/x86/mm/init_64.c Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27perf/x86/intel: Fix linear IP of PEBS real_ip on Haswell and later CPUsStephane Eranian1-8/+17
this patch fix a bug in how the pebs->real_ip is handled in the PEBS handler. real_ip only exists in Haswell and later processor. It is actually the eventing IP, i.e., where the event occurred. As opposed to the pebs->ip which is the PEBS interrupt IP which is always off by one. The problem is that the real_ip just like the IP needs to be fixed up because PEBS does not record all the machine state registers, and in particular the code segement (cs). This is why we have the set_linear_ip() function. The problem was that set_linear_ip() was only used on the pebs->ip and not the pebs->real_ip. We have profiles which ran into invalid callstacks because of this. Here is an example: ..... 0: ffffffffffffff80 recent entry, marker kernel v ..... 1: 000000000040044d <= user address in kernel space! ..... 2: fffffffffffffe00 marker enter user v ..... 3: 000000000040044d ..... 4: 00000000004004b6 oldest entry Debugging output in get_perf_callchain(): [ 857.769909] CALLCHAIN: CPU8 ip=40044d regs->cs=10 user_mode(regs)=0 The problem is that the kernel entry in 1: points to a user level address. How can that be? The reason is that with PEBS sampling the instruction that caused the event to occur and the instruction where the CPU was when the interrupt was posted may be far apart. And sometime during that time window, the privilege level may change. This happens, for instance, when the PEBS sample is taken close to a kernel entry point. Here PEBS, eventing IP (real_ip) captured a user level instruction. But by the time the PMU interrupt fired, the processor had already entered kernel space. This is why the debug output shows a user address with user_mode() false. The problem comes from PEBS not recording the code segment (cs) register. The register is used in x86_64 to determine if executing in kernel vs user space. This is okay because the kernel has a software workaround called set_linear_ip(). But the issue in setup_pebs_sample_data() is that set_linear_ip() is never called on the real_ip value when it is available (Haswell and later) and precise_ip > 1. This patch fixes this problem and eliminates the callchain discrepancy. The patch restructures the code around set_linear_ip() to minimize the number of times the IP has to be set. Signed-off-by: Stephane Eranian <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27objtool: Add Clang supportJosh Poimboeuf1-0/+11
Since the ORC unwinder was made the default on x86_64, Clang-built defconfig kernels have triggered some new objtool warnings: drivers/gpu/drm/i915/i915_gpu_error.o: warning: objtool: i915_error_printf()+0x6c: return with modified stack frame drivers/gpu/drm/i915/intel_display.o: warning: objtool: pipe_config_err()+0xa6: return with modified stack frame The problem is that objtool has never seen clang-built binaries before. Shockingly enough, objtool is apparently able to follow the code flow mostly fine, except for one instruction sequence. Instead of a LEAVE instruction, clang restores RSP and RBP the long way: 67c: 48 89 ec mov %rbp,%rsp 67f: 5d pop %rbp Teach objtool about this new code sequence. Reported-and-test-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matthias Kaehlcke <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/fce88ce81c356eedcae7f00ed349cfaddb3363cc.1521741586.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27perf/x86: Update rdpmc_always_available static key to the modern APIDavidlohr Bueso2-5/+6
No changes in refcount semantics -- use DEFINE_STATIC_KEY_FALSE() for initialization and replace: static_key_slow_inc|dec() => static_branch_inc|dec() static_key_false() => static_branch_unlikely() Added a '_key' suffix to rdpmc_always_available, for better self-documentation. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-27sched/core: Update preempt_notifier_key to modern APIDavidlohr Bueso1-6/+6
No changes in refcount semantics, use DEFINE_STATIC_KEY_FALSE() for initialization and replace: static_key_slow_inc|dec() => static_branch_inc|dec() static_key_false() => static_branch_unlikely() Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-03-26net/mlx5e: Sync netdev vxlan ports at openShahar Klein1-6/+3
When mlx5_core is loaded it is expected to sync ports with all vxlan devices so it can support vxlan encap/decap. This is done via udp_tunnel_get_rx_info(). Currently this call is set in mlx5e_nic_enable() and if the netdev is not in NETREG_REGISTERED state it will not be called. Normally on load the netdev state is not NETREG_REGISTERED so udp_tunnel_get_rx_info() will not be called. Moving udp_tunnel_get_rx_info() to mlx5e_open() so it will be called on netdev UP event and allow encap/decap. Fixes: 610e89e05c3f ("net/mlx5e: Don't sync netdev state when not registered") Signed-off-by: Shahar Klein <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Avoid using the ipv6 stub in the TC offload neigh update pathOr Gerlitz2-4/+4
Currently we use the global ipv6_stub var to access the ipv6 global nd table. This practice gets us to troubles when the stub is only partially set e.g when ipv6 is loaded under the disabled policy. In this case, as of commit 343d60aada5a ("ipv6: change ipv6_stub_impl.ipv6_dst_lookup to take net argument") the stub is not null, but stub->nd_tbl is and we crash. As we can access the ipv6 nd_tbl directly, the fix is just to avoid the reference through the stub. There is one place in the code where we issue ipv6 route lookup and keep doing it through the stub, but that mentioned commit makes sure we get -EAFNOSUPPORT from the stack. Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow") Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Aviv Heller <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Fix memory usage issues in offloading TC flowsJianbo Liu1-8/+8
For NIC flows, the parsed attributes are not freed when we exit successfully from mlx5e_configure_flower(). There is possible double free for eswitch flows. If error is returned from rhashtable_insert_fast(), the parse attrs will be freed in mlx5e_tc_del_flow(), but they will be freed again before exiting mlx5e_configure_flower(). To fix both issues we do the following: (1) change the condition that determines if to issue the free call to check if this flow is NIC flow, or it does not have encap action. (2) reorder the code such that that the check and free calls are done before we attempt to add into the hash table. Fixes: 232c001398ae ('net/mlx5e: Add support to neighbour update flow') Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Or Gerlitz <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Fix traffic being dropped on VF representorRoi Dayan1-2/+7
Increase representor netdev RQ size to avoid dropped packets. The current size (two) is just too small to keep up with conventional slow path traffic patterns. Also match the SQ size to the RQ size. Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Paul Blakey <[email protected]> Reviewed-by: Or Gerlitz <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Verify coalescing parameters in rangeMoshe Shemesh1-0/+17
Add check of coalescing parameters received through ethtool are within range of values supported by the HW. Driver gets the coalescing rx/tx-usecs and rx/tx-frames as set by the users through ethtool. The ethtool support up to 32 bit value for each. However, mlx5 modify cq limits the coalescing time parameter to 12 bit and coalescing frames parameters to 16 bits. Return out of range error if user tries to set these parameters to higher values. Fixes: f62b8bb8f2d3 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by: Moshe Shemesh <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5: Make eswitch support to depend on switchdevOr Gerlitz3-5/+3
Add dependancy for switchdev to be congfigured as any user-space control plane SW is expected to use the HW switchdev ID to locate the representors related to VFs of a certain PF and apply SW/offloaded switching on them. Fixes: e80541ecabd5 ('net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig') Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Use 32 bits to store VF representor SQ numberOr Gerlitz1-3/+3
SQs are 32 and not 16 bits, hence it's wrong to use only 16 bits to store the sq number for which are going to set steering rule, fix that. Fixes: cb67b832921c ('net/mlx5e: Introduce SRIOV VF representors') Signed-off-by: Or Gerlitz <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net/mlx5e: Don't override vport admin link state in switchdev modeJianbo Liu1-5/+6
The vport admin original link state will be re-applied after returning back to legacy mode, it is not right to change the admin link state value when in switchdev mode. Use direct vport commands to alter logical vport state in netdev representor open/close flows rather than the administrative eswitch API. Fixes: 20a1ea674783 ('net/mlx5e: Support VF vport link state control for SRIOV switchdev mode') Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Reviewed-by: Or Gerlitz <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2018-03-26net: dsa: mt7530: fix module autoloading for OF platform driversSean Wang1-0/+1
It's required to create a modules.alias via MODULE_DEVICE_TABLE helper for the OF platform driver. Otherwise, module autoloading cannot work. Signed-off-by: Sean Wang <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26net: dsa: mt7530: remove redundant MODULE_ALIAS entriesSean Wang1-1/+0
MODULE_ALIAS exports information to allow the module to be auto-loaded at boot for the drivers registered using legacy platform registration. However, currently the driver is always used by DT-only platform, MODULE_ALIAS is redundant and should be removed properly. Signed-off-by: Sean Wang <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26vhost_net: add missing lock nesting notationJason Wang1-2/+2
We try to hold TX virtqueue mutex in vhost_net_rx_peek_head_len() after RX virtqueue mutex is held in handle_rx(). This requires an appropriate lock nesting notation to calm down deadlock detector. Fixes: 0308813724606 ("vhost_net: basic polling support") Reported-by: [email protected] Signed-off-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26net/usb/qmi_wwan.c: Add USB id for lt4120 modemTorsten Hilbrich1-0/+1
This is needed to support the modem found in HP EliteBook 820 G3. Signed-off-by: Torsten Hilbrich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26team: move dev_mc_sync after master_upper_dev_link in team_port_addXin Long1-7/+5
The same fix as in 'bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave' is needed for team driver. The panic can be reproduced easily: ip link add team1 type team ip link set team1 up ip link add link team1 vlan1 type vlan id 80 ip link set vlan1 master team1 Fixes: cb41c997d444 ("team: team should sync the port's uc/mc addrs when add a port") Signed-off-by: Xin Long <[email protected]> Acked-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26Merge branch 'bond-hwaddr-sync-fixes'David S. Miller1-36/+37
Xin Long says: ==================== bonding: a bunch of fixes for dev hwaddr sync in bond_enslave This patchset is mainly to fix a crash when adding vlan as slave of bond which is also the parent link in patch 2/3, and also fix some err process problems in bond_enslave in patch 1/3 and 3/3. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-03-26bonding: process the err returned by dev_set_allmulti properly in bond_enslaveXin Long1-1/+4
When dev_set_promiscuity(1) succeeds but dev_set_allmulti(1) fails, dev_set_promiscuity(-1) should be done before going to the err path. Otherwise, dev->promiscuity will leak. Fixes: 7e1a1ac1fbaa ("bonding: Check return of dev_set_promiscuity/allmulti") Signed-off-by: Xin Long <[email protected]> Acked-by: Andy Gospodarek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26bonding: move dev_mc_sync after master_upper_dev_link in bond_enslaveXin Long1-38/+35
Beniamino found a crash when adding vlan as slave of bond which is also the parent link: ip link add bond1 type bond ip link set bond1 up ip link add link bond1 vlan1 type vlan id 80 ip link set vlan1 master bond1 The call trace is as below: [<ffffffffa850842a>] queued_spin_lock_slowpath+0xb/0xf [<ffffffffa8515680>] _raw_spin_lock+0x20/0x30 [<ffffffffa83f6f07>] dev_mc_sync+0x37/0x80 [<ffffffffc08687dc>] vlan_dev_set_rx_mode+0x1c/0x30 [8021q] [<ffffffffa83efd2a>] __dev_set_rx_mode+0x5a/0xa0 [<ffffffffa83f7138>] dev_mc_sync_multiple+0x78/0x80 [<ffffffffc084127c>] bond_enslave+0x67c/0x1190 [bonding] [<ffffffffa8401909>] do_setlink+0x9c9/0xe50 [<ffffffffa8403bf2>] rtnl_newlink+0x522/0x880 [<ffffffffa8403ff7>] rtnetlink_rcv_msg+0xa7/0x260 [<ffffffffa8424ecb>] netlink_rcv_skb+0xab/0xc0 [<ffffffffa83fe498>] rtnetlink_rcv+0x28/0x30 [<ffffffffa8424850>] netlink_unicast+0x170/0x210 [<ffffffffa8424bf8>] netlink_sendmsg+0x308/0x420 [<ffffffffa83cc396>] sock_sendmsg+0xb6/0xf0 This is actually a dead lock caused by sync slave hwaddr from master when the master is the slave's 'slave'. This dead loop check is actually done by netdev_master_upper_dev_link. However, Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave") moved it after dev_mc_sync. This patch is to fix it by moving dev_mc_sync after master_upper_dev_link, so that this loop check would be earlier than dev_mc_sync. It also moves if (mode == BOND_MODE_8023AD) into if (!bond_uses_primary) clause as an improvement. Note team driver also has this issue, I will fix it in another patch. Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave") Reported-by: Beniamino Galvani <[email protected]> Signed-off-by: Xin Long <[email protected]> Acked-by: Andy Gospodarek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26bonding: fix the err path for dev hwaddr sync in bond_enslaveXin Long1-4/+5
vlan_vids_add_by_dev is called right after dev hwaddr sync, so on the err path it should unsync dev hwaddr. Otherwise, the slave dev's hwaddr will never be unsync when this err happens. Fixes: 1ff412ad7714 ("bonding: change the bond's vlan syncing functions with the standard ones") Signed-off-by: Xin Long <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Acked-by: Andy Gospodarek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26net: sched, fix OOO packets with pfifo_fastJohn Fastabend2-4/+14
After the qdisc lock was dropped in pfifo_fast we allow multiple enqueue threads and dequeue threads to run in parallel. On the enqueue side the skb bit ooo_okay is used to ensure all related skbs are enqueued in-order. On the dequeue side though there is no similar logic. What we observe is with fewer queues than CPUs it is possible to re-order packets when two instances of __qdisc_run() are running in parallel. Each thread will dequeue a skb and then whichever thread calls the ndo op first will be sent on the wire. This doesn't typically happen because qdisc_run() is usually triggered by the same core that did the enqueue. However, drivers will trigger __netif_schedule() when queues are transitioning from stopped to awake using the netif_tx_wake_* APIs. When this happens netif_schedule() calls qdisc_run() on the same CPU that did the netif_tx_wake_* which is usually done in the interrupt completion context. This CPU is selected with the irq affinity which is unrelated to the enqueue operations. To resolve this we add a RUNNING bit to the qdisc to ensure only a single dequeue per qdisc is running. Enqueue and dequeue operations can still run in parallel and also on multi queue NICs we can still have a dequeue in-flight per qdisc, which is typically per CPU. Fixes: c5ad119fb6c0 ("net: sched: pfifo_fast use skb_array") Reported-by: Jakob Unterwurzacher <[email protected]> Signed-off-by: John Fastabend <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26net: qmi_wwan: add BroadMobi BM806U 2020:2033Pawel Dembicki1-0/+1
BroadMobi BM806U is an Qualcomm MDM9225 based 3G/4G modem. Tested hardware BM806U is mounted on D-Link DWR-921-C3 router. The USB id is added to qmi_wwan.c to allow QMI communication with the BM806U. Tested on 4.14 kernel and OpenWRT. Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26Documentation/isdn: check and fix dead links ...Sanjeev Gupta4-12/+14
and switch to https where possible. All links have been eyeballed to verify that the domains have not changed, etc. Signed-off-by: Sanjeev Gupta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-26ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()Stefan Roese1-1/+1
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB area, as the page offset is outside of the VMA range (size), which is currently used as size parameter in snd_pcm_lib_default_mmap(). By using the DMA buffer size (dma_bytes) instead, the complete DMA buffer can be mmapp'ed and the issue is fixed. This issue was detected on an ARM platform (TI AM57xx) using the RME HDSP MADI PCIe soundcard. Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available") Signed-off-by: Stefan Roese <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-03-26MAINTAINERS: UNICORE32: Change email accountGuan Xuetao1-2/+2
Change email account for unicore32 arch and pkunity soc drivers Since old email server mprc.pku.edu.cn was blocked in recent years Signed-off-by: Guan Xuetao <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26staging: iio: remove iio-trig-bfin-timer driverArnd Bergmann7-344/+0
The blackfin architecture is getting removed, so the timer trigger driver is now obsolete. Since this is the last remaining iio trigger driver in staging, I'm removing the entire directory. Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Aaron Wu <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26tty: hvc: remove tile driverArnd Bergmann2-197/+0
The Tile architecture is obsolete and getting removed from the kernel, this removes the corresponding console driver as well. Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26tty: remove bfin_jtag_comm and hvc_bfin_jtag driversArnd Bergmann6-481/+0
The blackfin architecture is getting removed, so these drivers are not needed any more. Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Aaron Wu <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26serial: remove tile uart driverArnd Bergmann3-699/+0
The tile architecture is getting removed, and this driver is useless without it. Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26serial: remove m32r_sio driverArnd Bergmann4-1233/+0
The m32r architecture is getting removed, so we don't need this any more. Acked-by: Nicolas Pitre <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26serial: remove blackfin driversArnd Bergmann5-2725/+0
The blackfin architecture is getting removed, so both the bfin_uart and bfin_sport_uart can be removed as well. Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Aaron Wu <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26serial: remove cris/etrax uart driversArnd Bergmann6-5376/+0
The cris architecture is getting removed, so we don't need the uart driver any more. Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Jesper Nilsson <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-03-26usb: Remove Blackfin references in USB supportAaron Wu4-8/+0
The website is no longer used for tracking bugs. Signed-off-by: Aaron Wu <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>