Jaedon Shin [Tue, 6 Feb 2018 03:13:21 +0000 (12:13 +0900)]
MIPS: BMIPS: Fix section mismatch warning
Remove the __init annotation from bmips_cpu_setup() to avoid the
following warning.
WARNING: vmlinux.o(.text+0x35c950): Section mismatch in reference from the function brcmstb_pm_s3() to the function .init.text:bmips_cpu_setup()
The function brcmstb_pm_s3() references
the function __init bmips_cpu_setup().
This is often because brcmstb_pm_s3 lacks a __init
annotation or the annotation of bmips_cpu_setup is wrong.
When uncore_pci_remove() runs, it tries to get the package ID to
clear the value of uncore_extra_pci_dev[].dev[] by using
topology_phys_to_logical_pkg(). The warning messesages are
shown because topology_phys_to_logical_pkg() returns -1.
Harish [Tue, 13 Feb 2018 06:32:55 +0000 (12:02 +0530)]
selftests/powerpc: Fix to use ucontext_t instead of struct ucontext
With glibc 2.26 'struct ucontext' is removed to improve POSIX
compliance, which breaks powerpc/alignment_handler selftest. Fix the
test by using ucontext_t. Tested on ppc, works with older glibc
versions as well.
Fixes the following:
alignment_handler.c: In function ‘sighandler’:
alignment_handler.c:68:5: error: dereferencing pointer to incomplete type ‘struct ucontext’
ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
Guenter Roeck [Mon, 12 Feb 2018 22:34:07 +0000 (14:34 -0800)]
powerpc/kdump: Fix powernv build break when KEXEC_CORE=n
If KEXEC_CORE is not enabled, powernv builds fail as follows.
arch/powerpc/platforms/powernv/smp.c: In function 'pnv_smp_cpu_kill_self':
arch/powerpc/platforms/powernv/smp.c:236:4: error:
implicit declaration of function 'crash_ipi_callback'
Add dummy function calls, similar to kdump_in_progress(), to solve the
problem.
Fixes: 4145f358644b ("powernv/kdump: Fix cases where the kdump kernel can get HMI's") Signed-off-by: Guenter Roeck <[email protected]> Acked-by: Balbir Singh <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
Guenter Roeck [Mon, 12 Feb 2018 22:34:08 +0000 (14:34 -0800)]
powerpc/pseries: Fix build break for SPLPAR=n and CPU hotplug
Commit e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with
memoryless nodes") adds an unconditional call to
find_and_online_cpu_nid(), which is only declared if CONFIG_PPC_SPLPAR
is enabled. This results in the following build error if this is not
the case.
arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu':
arch/powerpc/platforms/pseries/hotplug-cpu.c:369:
undefined reference to `.find_and_online_cpu_nid'
Follow the guideline provided by similar functions and provide a dummy
function if CONFIG_PPC_SPLPAR is not enabled. This also moves the
external function declaration into an include file where it should be.
Fixes: e67e02a544e9 ("powerpc/pseries: Fix cpu hotplug crash with memoryless nodes") Signed-off-by: Guenter Roeck <[email protected]>
[mpe: Change subject to emphasise the build fix] Signed-off-by: Michael Ellerman <[email protected]>
On powerpc we allocate page table pages from slab caches of different
sizes. Currently we have a constructor that zeroes out the objects when
we allocate them for the first time.
We expect the objects to be zeroed out when we free the the object
back to slab cache. This happens in the unmap path. For hugetlb pages
we call huge_pte_get_and_clear() to do that.
With the current configuration of page table size, both PUD and PGD
level tables are allocated from the same slab cache. At the PUD level,
we use the second half of the table to store the slot information. But
we never clear that when unmapping.
When such a freed object is then allocated for a PGD page, the second
half of the page table page will not be zeroed as expected. This
results in a kernel crash.
Fix it by always clearing PGD pages when they're allocated.
Signed-off-by: Aneesh Kumar K.V <[email protected]>
[mpe: Change log wording and formatting, add whitespace] Signed-off-by: Michael Ellerman <[email protected]>
powerpc/mm/hash64: Store the slot information at the right offset for hugetlb
The hugetlb pte entries are at the PMD and PUD level, so we can't use
PTRS_PER_PTE to find the second half of the page table. Use the right
offset for PUD/PMD to get to the second half of the table.
Fixes: bf9a95f9a648 ("powerpc: Free up four 64K PTE bits in 64K backed HPTE pages") Signed-off-by: Aneesh Kumar K.V <[email protected]> Reviewed-by: Ram Pai <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
To support memory keys, we moved the hash pte slot information to the
second half of the page table. This was ok with PTE entries at level
4 (PTE page) and level 3 (PMD). We already allocate larger page table
pages at those levels to accomodate extra details. For level 4 we
already have the extra space which was used to track 4k hash page
table entry details and at level 3 the extra space was allocated to
track the THP details.
With hugetlbfs PTE, we used this extra space at the PMD level to store
the slot details. But we also support hugetlbfs PTE at PUD level for
16GB pages and PUD level page didn't allocate extra space. This
resulted in memory corruption.
Fix this by allocating extra space at PUD level when HUGETLB is
enabled.
Fixes: bf9a95f9a648 ("powerpc: Free up four 64K PTE bits in 64K backed HPTE pages") Signed-off-by: Aneesh Kumar K.V <[email protected]> Reviewed-by: Ram Pai <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
powerpc/mm: Flush radix process translations when setting MMU type
Radix guests do normally invalidate process-scoped translations when a
new pid is allocated but migrated guests do not invalidate these so
migrated guests crash sometime, especially easy to reproduce with
migration happening within first 10 seconds after the guest boot start
on the same machine.
This adds the "Invalidate process-scoped translations" flush to fix
radix guests migration.
Nicholas Piggin [Thu, 8 Feb 2018 09:18:38 +0000 (19:18 +1000)]
powerpc/vas: Don't set uses_vas for kernel windows
cp_abort is only required for user windows, because kernel context
must not be preempted between a copy/paste pair.
Without this patch, the init task gets used_vas set when it runs the
nx842_powernv_init initcall, which opens windows for kernel usage.
used_vas is then never cleared anywhere, so it gets propagated into
all other tasks. It's a property of the address space, so it should
really be cleared when a new mm is created (or in dup_mmap if the
mmaps are marked as VM_DONTCOPY). For now we seem to have no such
driver, so leave that for another patch.
Sam Bobroff [Mon, 12 Feb 2018 00:19:29 +0000 (11:19 +1100)]
powerpc/pseries: Enable RAS hotplug events later
Currently if the kernel receives a memory hot-unplug event early
enough, it may get stuck in an infinite loop in
dissolve_free_huge_pages(). This appears as a stall just after:
pseries-hotplug-mem: Attempting to hot-remove XX LMB(s) at YYYYYYYY
It appears to be caused by "minimum_order" being uninitialized, due to
init_ras_IRQ() executing before hugetlb_init().
To correct this, extract the part of init_ras_IRQ() that enables
hotplug event processing and place it in the machine_late_initcall
phase, which is guaranteed to be after hugetlb_init() is called.
Peter Zijlstra [Tue, 6 Feb 2018 16:52:13 +0000 (17:52 +0100)]
sched/core: Fix DEBUG_SPINLOCK annotation for rq->lock
Mark noticed that he had sporadic "spinlock recursion" warnings from
the DEBUG_SPINLOCK code. Now rq->lock is special in that the owner
changes in the middle of a context switch.
It so happens that we fix up the lock.owner too late, @prev can run
(remotely) the moment prev->on_cpu is cleared, this then allows @prev
to again try and acquire this rq->lock and trigger this warning.
So we have to switch lock.owner before clearing prev->on_cpu.
Do this by moving the DEBUG_SPINLOCK annotation from after switch_to()
to before switch_to() and collect all lockdep annotations there into
prepare_lock_switch() to mirror the existing finish_lock_switch().
Wen Yang [Tue, 6 Feb 2018 01:53:28 +0000 (09:53 +0800)]
sched/rt: Make update_curr_rt() more accurate
rq->clock_task may be updated between the two calls of
rq_clock_task() in update_curr_rt(). Calling rq_clock_task() only
once makes it more accurate and efficient, taking update_curr() as
reference.
Wen Yang [Tue, 6 Feb 2018 01:55:48 +0000 (09:55 +0800)]
sched/deadline: Make update_curr_dl() more accurate
rq->clock_task may be updated between the two calls of
rq_clock_task() in update_curr_dl(). Calling rq_clock_task() only
once makes it more accurate and efficient, taking update_curr() as
reference.
Ingo Molnar [Tue, 13 Feb 2018 07:26:17 +0000 (08:26 +0100)]
selftests/x86/pkeys: Remove unused functions
This also gets rid of two build warnings:
protection_keys.c: In function ‘dumpit’:
protection_keys.c:419:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
write(1, buf, nr_read);
^~~~~~~~~~~~~~~~~~~~~~
selftests/x86: Clean up and document sscanf() usage
Replace a couple of magically connected buffer length literal constants with
a common definition that makes their relationship obvious. Also document
why our sscanf() usage is safe.
selftests/x86: Fix vDSO selftest segfault for vsyscall=none
The vDSO selftest tries to execute a vsyscall unconditionally, even if it
is not present on the test system (e.g. if booted with vsyscall=none or
with CONFIG_LEGACY_VSYSCALL_NONE=y set. Fix this by copying (and tweaking)
the vsyscall check from test_vsyscall.c
f09d160992d1 ("x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros")
... one of my suggested improvements triggered a frame pointer warning:
arch/x86/entry/entry_64.o: warning: objtool: paranoid_entry()+0x11: call without frame pointer save/setup
The warning is correct for the build-time code, but it's actually not
relevant at runtime because of paravirt patching. The paravirt swapgs
call gets replaced with either a SWAPGS instruction or NOPs at runtime.
Go back to the previous behavior by removing the ELF function annotation
for paranoid_entry() and adding an unwind hint, which effectively
silences the warning.
x86/entry/64: Get rid of the ALLOC_PT_GPREGS_ON_STACK and SAVE_AND_CLEAR_REGS macros
Previously, error_entry() and paranoid_entry() saved the GP registers
onto stack space previously allocated by its callers. Combine these two
steps in the callers, and use the generic PUSH_AND_CLEAR_REGS macro
for that.
This adds a significant amount ot text size. However, Ingo Molnar points
out that:
"these numbers also _very_ significantly over-represent the
extra footprint. The assumptions that resulted in
us compressing the IRQ entry code have changed very
significantly with the new x86 IRQ allocation code we
introduced in the last year:
- IRQ vectors are usually populated in tightly clustered
groups.
With our new vector allocator code the typical per CPU
allocation percentage on x86 systems is ~3 device vectors
and ~10 fixed vectors out of ~220 vectors - i.e. a very
low ~6% utilization (!). [...]
The days where we allocated a lot of vectors on every
CPU and the compression of the IRQ entry code text
mattered are over.
- Another issue is that only a small minority of vectors
is frequent enough to actually matter to cache utilization
in practice: 3-4 key IPIs and 1-2 device IRQs at most - and
those vectors tend to be tightly clustered as well into about
two groups, and are probably already on 2-3 cache lines in
practice.
For the common case of 'cache cold' IRQs it's the depth of
the call chain and the fragmentation of the resulting I$
that should be the main performance limit - not the overall
size of it.
- The CPU side cost of IRQ delivery is still very expensive
even in the best, most cached case, as in 'over a thousand
cycles'. So much stuff is done that maybe contemporary x86
IRQ entry microcode already prefetches the IDT entry and its
expected call target address."[*]
The "testb $3, CS(%rsp)" instruction in the idtentry macro does not need
modification. Previously, %rsp was manually decreased by 15*8; with
this patch, %rsp is decreased by 15 pushq instructions.
x86/entry/64: Use PUSH_AND_CLEAN_REGS in more cases
entry_SYSCALL_64_after_hwframe() and nmi() can be converted to use
PUSH_AND_CLEAN_REGS instead of opencoded variants thereof. Due to
the interleaving, the additional XOR-based clearing of R8 and R9
in entry_SYSCALL_64_after_hwframe() should not have any noticeable
negative implications.
x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro
Those instances where ALLOC_PT_GPREGS_ON_STACK is called just before
SAVE_AND_CLEAR_REGS can trivially be replaced by PUSH_AND_CLEAN_REGS.
This macro uses PUSH instead of MOV and should therefore be faster, at
least on newer CPUs.
x86/entry/64: Interleave XOR register clearing with PUSH instructions
Same as is done for syscalls, interleave XOR with PUSH instructions
for exceptions/interrupts, in order to minimize the cost of the
additional instructions required for register clearing.
KarimAllah Ahmed [Sat, 10 Feb 2018 23:39:26 +0000 (23:39 +0000)]
KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap
We either clear the CPU_BASED_USE_MSR_BITMAPS and end up intercepting all
MSR accesses or create a valid L02 MSR bitmap and use that. This decision
has to be made every time we evaluate whether we are going to generate the
L02 MSR bitmap.
Before commit:
d28b387fb74d ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
... this was probably OK since the decision was always identical.
This is no longer the case now since the MSR bitmap might actually
change once we decide to not intercept SPEC_CTRL and PRED_CMD.
KarimAllah Ahmed [Sat, 10 Feb 2018 23:39:25 +0000 (23:39 +0000)]
X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs
These two variables should check whether SPEC_CTRL and PRED_CMD are
supposed to be passed through to L2 guests or not. While
msr_write_intercepted_l01 would return 'true' if it is not passed through.
So just invert the result of msr_write_intercepted_l01 to implement the
correct semantics.
David Woodhouse [Sat, 10 Feb 2018 23:39:24 +0000 (23:39 +0000)]
KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods
With retpoline, tight loops of "call this function for every XXX" are
very much pessimised by taking a prediction miss *every* time. This one
is by far the biggest contributor to the guest launch time with retpoline.
By marking the iterator slot_handle_…() functions always_inline, we can
ensure that the indirect function call can be optimised away into a
direct call and it actually generates slightly smaller code because
some of the other conditionals can get optimised away too.
Performance is now pretty close to what we see with nospectre_v2 on
the command line.
We cannot call C functions like that, without marking all the
call-clobbered registers as, well, clobbered. We might have got away
with it for now because the __ibp_barrier() function was *fairly*
unlikely to actually use any other registers. But no. Just no.
David Woodhouse [Mon, 12 Feb 2018 15:27:34 +0000 (15:27 +0000)]
x86/speculation: Correct Speculation Control microcode blacklist again
Arjan points out that the Intel document only clears the 0xc2 microcode
on *some* parts with CPUID 506E3 (INTEL_FAM6_SKYLAKE_DESKTOP stepping 3).
For the Skylake H/S platform it's OK but for Skylake E3 which has the
same CPUID it isn't (yet) cleared.
So removing it from the blacklist was premature. Put it back for now.
Also, Arjan assures me that the 0x84 microcode for Kaby Lake which was
featured in one of the early revisions of the Intel document was never
released to the public, and won't be until/unless it is also validated
as safe. So those can change to 0x80 which is what all *other* versions
of the doc have identified.
Once the retrospective testing of existing public microcodes is done, we
should be back into a mode where new microcodes are only released in
batches and we shouldn't even need to update the blacklist for those
anyway, so this tweaking of the list isn't expected to be a thing which
keeps happening.
Chris Wilson [Thu, 8 Feb 2018 08:51:51 +0000 (08:51 +0000)]
drm/i915: Avoid truncation before clamping userspace's priority value
Userspace provides a 64b value for the priority, we need to be careful
to preserve the full range before validation to prevent truncation (and
letting an illegal value pass).
Chris Wilson [Thu, 8 Feb 2018 10:24:03 +0000 (10:24 +0000)]
drm/i915/perf: Fix compiler warning for string truncation
drivers/gpu/drm/i915/i915_oa_cnl.c: In function ‘i915_perf_load_test_config_cnl’:
drivers/gpu/drm/i915/i915_oa_cnl.c:99:2: error: ‘strncpy’ output truncated before terminating nul copying 36 bytes from a string of the same length [-Werror=stringop-truncation]
Chris Wilson [Thu, 8 Feb 2018 10:24:02 +0000 (10:24 +0000)]
drm/i915/perf: Fix compiler warning for string truncation
drivers/gpu/drm/i915/i915_oa_cflgt3.c: In function ‘i915_perf_load_test_config_cflgt3’:
drivers/gpu/drm/i915/i915_oa_cflgt3.c:87:2: error: ‘strncpy’ output truncated before terminating nul copying 36 bytes from a string of the same length [-Werror=stringop-truncation]
This will happen if the temperature reported by the chip is lower than
the offset temperature. This has been seen in the field if "Sense MI Skew"
and/or "Sense MI Offset" BIOS parameters were set to unexpected values.
Let's report a temperature of 0 degrees C in that case.
Fixes: 1b50b776355f ("hwmon: (k10temp) Add support for temperature offsets") Signed-off-by: Guenter Roeck <[email protected]>
Hans de Goede [Mon, 12 Feb 2018 19:46:29 +0000 (20:46 +0100)]
Revert "extcon: axp288: Redo charger type detection a couple of seconds after probe()"
Redoing the charger type detection to give the usb-role-switch code time
to properly set the role-switch is no good for mainline, since the
usb-role-switch code is not yet in mainline (my bad, sorry).
Also once we've that code there are better ways to fix this which are
not prone to racing as doing a retry after 2 seconds is.
Roland Dreier [Thu, 11 Jan 2018 21:38:15 +0000 (13:38 -0800)]
nvme: Don't use a stack buffer for keep-alive command
In nvme_keep_alive() we pass a request with a pointer to an NVMe command on
the stack into blk_execute_rq_nowait(). However, the block layer doesn't
guarantee that the request is fully queued before blk_execute_rq_nowait()
returns. If not, and the request is queued after nvme_keep_alive() returns,
then we'll end up using stack memory that might have been overwritten to
form the NVMe command we pass to hardware.
Fix this by keeping a special command struct in the nvme_ctrl struct right
next to the delayed work struct used for keep-alives.
Mika Westerberg [Mon, 12 Feb 2018 14:10:20 +0000 (17:10 +0300)]
net: thunderbolt: Run disconnect flow asynchronously when logout is received
The control channel calls registered callbacks when control messages
such as XDomain protocol messages are received. The control channel
handling is done in a worker running on system workqueue which means the
networking driver can't run tear down flow which includes sending
disconnect request and waiting for a reply in the same worker. Otherwise
reply is never received (as the work is already running) and the
operation times out.
To fix this run disconnect ThunderboltIP flow asynchronously once
ThunderboltIP logout message is received.
Mika Westerberg [Mon, 12 Feb 2018 14:10:19 +0000 (17:10 +0300)]
net: thunderbolt: Tear down connection properly on suspend
When suspending to mem or disk the Thunderbolt controller typically goes
down as well tearing down the connection automatically. However, when
suspend to idle is used this does not happen so we need to make sure the
connection is properly disconnected before it can be re-established
during resume.
Linus Torvalds [Mon, 12 Feb 2018 16:57:21 +0000 (08:57 -0800)]
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"This fixes the following issues:
- oversize stack frames on mn10300 in sha3-generic
- warning on old compilers in sha3-generic
- API error in sun4i_ss_prng
- potential dead-lock in sun4i_ss_prng
- null-pointer dereference in sha512-mb
- endless loop when DECO acquire fails in caam
- kernel oops when hashing empty message in talitos"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generate
crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generate
crypto: caam - fix endless loop when DECO acquire fails
crypto: sha3-generic - Use __optimize to support old compilers
compiler-gcc.h: __nostackprotector needs gcc-4.4 and up
compiler-gcc.h: Introduce __optimize function attribute
crypto: sha3-generic - deal with oversize stack frames
crypto: talitos - fix Kernel Oops on hashing an empty file
crypto: sha512-mb - initialize pending lengths correctly
sh_eth: Remove obsolete explicit clock handling for WoL
Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
is manually kept running during system suspend, to make sure the device
stays active.
Since commits 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
sources active during system suspend") and 744dddcae84441b1 ("clk:
renesas: mstp: Keep wakeup sources active during system suspend"), this
workaround is no longer needed. Hence remove all explicit clock
handling to keep the device active.
ravb: Remove obsolete explicit clock handling for WoL
Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
is manually kept running during system suspend, to make sure the device
stays active.
Since commit 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
sources active during system suspend") , this workaround is no longer
needed. Hence remove all explicit clock handling to keep the device
active.
Ingo van Lil [Mon, 12 Feb 2018 11:02:52 +0000 (12:02 +0100)]
net: phy: fix wrong mask to phy_modify()
When forcing a specific link mode, the PHY driver must clear the
existing speed and duplex bits in BMCR while preserving some other
control bits. This logic was accidentally inverted with the introduction
of phy_modify().
Fixes: fea23fb591cc ("net: phy: convert read-modify-write to phy_modify()") Signed-off-by: Ingo van Lil <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Ilya Lesokhin [Mon, 12 Feb 2018 10:57:04 +0000 (12:57 +0200)]
tcp: Honor the eor bit in tcp_mtu_probe
Avoid SKB coalescing if eor bit is set in one of the relevant
SKBs.
Fixes: c134ecb87817 ("tcp: Make use of MSG_EOR in tcp_sendmsg") Signed-off-by: Ilya Lesokhin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Xin Long [Mon, 12 Feb 2018 10:29:51 +0000 (18:29 +0800)]
sctp: add SCTP_CID_I_DATA and SCTP_CID_I_FWD_TSN conversion in sctp_cname
After the support for SCTP_CID_I_DATA and SCTP_CID_I_FWD_TSN chunks,
the corresp conversion in sctp_cname should also be added. Otherwise,
in some places, pr_debug will print them as "unknown chunk".
Xin Long [Mon, 12 Feb 2018 09:15:40 +0000 (17:15 +0800)]
bridge: check brport attr show in brport_show
Now br_sysfs_if file flush doesn't have attr show. To read it will
cause kernel panic after users chmod u+r this file.
Xiong found this issue when running the commands:
ip link add br0 type bridge
ip link add type veth
ip link set veth0 master br0
chmod u+r /sys/devices/virtual/net/veth0/brport/flush
timeout 3 cat /sys/devices/virtual/net/veth0/brport/flush
kernel crashed with NULL a pointer dereference call trace.
This patch is to fix it by return -EINVAL when brport_attr->show
is null, just the same as the check for brport_attr->store in
brport_store().
Fixes: 9cf637473c85 ("bridge: add sysfs hook to flush forwarding table") Reported-by: Xiong Zhou <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Corentin Labbe [Thu, 8 Feb 2018 19:39:20 +0000 (19:39 +0000)]
ia64: fix build failure with CONFIG_SWIOTLB
arch/ia64/kernel/pci-swiotlb.c is removed in commit 4fac8076df85 ("ia64: clean up swiotlb support")
but pci-swiotlb.o is still present in Makefile, and so build fail when
CONFIG_SWIOTLB is enabled.
Fix the build failure by removing pci-swiotlb.o from makefile
Fixes: 4fac8076df85 ("ia64: clean up swiotlb support") Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
arm64: Add missing Falkor part number for branch predictor hardening
References to CPU part number MIDR_QCOM_FALKOR were dropped from the
mailing list patch due to mainline/arm64 branch dependency. So this
patch adds the missing part number.
Commit f85942207516 (x86: PM: Make APM idle driver initialize polling
state) made apm_init() call cpuidle_poll_state_init(), but that only
is defined for CONFIG_CPU_IDLE set, so make the empty stub of it
available for CONFIG_CPU_IDLE unset too to fix the resulting build
issue.
Fixes: f85942207516 (x86: PM: Make APM idle driver initialize polling state) Cc: 4.14+ <[email protected]> # 4.14+ Signed-off-by: Rafael J. Wysocki <[email protected]>
Lukas Wunner [Sat, 10 Feb 2018 18:13:58 +0000 (19:13 +0100)]
PM / runtime: Update links_count also if !CONFIG_SRCU
Commit baa8809f6097 (PM / runtime: Optimize the use of device links)
added an invocation of pm_runtime_drop_link() to __device_link_del().
However there are two variants of that function, one for CONFIG_SRCU and
another for !CONFIG_SRCU, and the commit only modified the former.
Fixes: baa8809f6097 (PM / runtime: Optimize the use of device links) Cc: v4.10+ <[email protected]> # v4.10+ Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Tony Lindgren [Fri, 9 Feb 2018 16:11:26 +0000 (08:11 -0800)]
PM / wakeirq: Fix unbalanced IRQ enable for wakeirq
If a device is runtime PM suspended when we enter suspend and has
a dedicated wake IRQ, we can get the following warning:
WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
[ 102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [<c06117a8>] (dev_pm_arm_wake_irq+0x4c/0x60)
(dev_pm_arm_wake_irq) from [<c0618360>]
(device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from [<c0615948>]
(dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from [<c01ac7ac>]
(suspend_devices_and_enter+0x30c/0xf14)
(suspend_devices_and_enter) from [<c01adf20>]
(enter_state+0xad4/0xbd8)
(enter_state) from [<c01ad3ec>] (pm_suspend+0x38/0x98)
(pm_suspend) from [<c01ab3e8>] (state_store+0x68/0xc8)
This is because the dedicated wake IRQ for the device may have been
already enabled earlier by dev_pm_enable_wake_irq_check(). Fix the
issue by checking for runtime PM suspended status.
This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal. On resume, dmesg will have the warning above.
The reason why I have not run into this issue earlier has been that I
typically run my PM test cases from on a serial console instead over ssh.
Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend) Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Update cpuidle documentation using git logs and existing documentation
in Documentation/cpuidle/sysfs.txt. This might be useful for scripting
and tracking changes in the ABI.
Stefan Agner [Fri, 9 Feb 2018 12:21:42 +0000 (13:21 +0100)]
mtd: nand: vf610: set correct ooblayout
With commit 3cf32d180227 ("mtd: nand: vf610: switch to
mtd_ooblayout_ops") the driver started to use the NAND cores
default large page ooblayout. However, shortly after commit 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
changed the default layout to the old hamming layout, which is
not what vf610_nfc is using. Specify the default large page
layout explicitly.
Merge branch 'opp/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm into pm-opp
Pull and OPP update for 4.16-rc2 from Viresh Kumar.
* 'opp/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
opp: cpu: Replace GFP_ATOMIC with GFP_KERNEL in dev_pm_opp_init_cpufreq_table
Andy Shevchenko [Fri, 9 Feb 2018 15:38:34 +0000 (17:38 +0200)]
ACPI / bus: Remove checks in acpi_get_match_data()
As well as its sibling of_device_get_match_data() has no such checks,
no need to do it in acpi_get_match_data().
First of all, we are not supposed to call fwnode API like this without
driver attached.
Second, since __acpi_match_device() does check input parameter there is
no need to duplicate it outside.
And last but not least one, the API should still serve the cases when
ACPI device is enumerated via PRP0001. In such case driver has neither
ACPI table nor driver data there.
Andy Shevchenko [Fri, 9 Feb 2018 15:38:33 +0000 (17:38 +0200)]
ACPI / bus: Do not traverse through non-existed device table
When __acpi_match_device() is called it would be possible to have
ACPI ID table a NULL pointer. To avoid potential dereference,
check for this before traverse.
While here, remove redundant 'else'.
Note, this patch implies a bit of refactoring acpi_of_match_device()
to return pointer to OF ID when matched followed by refactoring
__acpi_match_device() to return either ACPI or OF ID when matches.
Jia-Ju Bai [Fri, 26 Jan 2018 08:48:49 +0000 (16:48 +0800)]
opp: cpu: Replace GFP_ATOMIC with GFP_KERNEL in dev_pm_opp_init_cpufreq_table
After checking all possible call chains to
dev_pm_opp_init_cpufreq_table() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
And dev_pm_opp_init_cpufreq_table() calls dev_pm_opp_get_opp_count(),
which calls mutex_lock that can sleep.
It indicates that atmtcp_v_send() can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
ACPI / EC: Restore polling during noirq suspend/resume phases
Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a
regression) modified the ACPI EC driver so that it doesn't switch
over to busy polling mode during noirq stages of system suspend and
resume in an attempt to fix an issue resulting from that behavior.
However, that modification introduced a system resume regression on
Thinkpad X240, so make the EC driver switch over to the polling mode
during noirq stages of system suspend and resume again, which
effectively reverts the problematic commit.
We should call dwc2_hsotg_enqueue_setup() after properly
setting lx_state. Because it may cause error-out from
dwc2_hsotg_enqueue_setup() due to wrong value in lx_state.
Issue can be reproduced by loading driver while connected
A-Connector (start in A-HOST mode) then disconnect A-Connector
to switch to B-DEVICE.
usb: dwc2: Add safety check in setting of descriptor chain pointers
In some cases device sending ZLP IN on non EP0 which
reassigning EP0 OUT descriptor pointer to that EP.
Dedicated for EP0 OUT descriptor multiple time re-used by
other EP while that descriptor already in use by EP0 OUT
for SETUP transaction. As result when SETUP packet received
BNA interrupt asserting.
In dwc2_hsotg_program_zlp() function dwc2_gadget_set_ep0_desc_chain()
must be called only for EP0.
Stefan Agner [Sun, 11 Feb 2018 23:14:42 +0000 (00:14 +0100)]
usb: gadget: fsl_udc_core: fix ep valid checks
Clang reports the following warning:
drivers/usb/gadget/udc/fsl_udc_core.c:1312:10: warning: address of array
'ep->name' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (ep->name)
~~ ~~~~^~~~
It seems that the authors intention was to check if the ep has been
configured through struct_ep_setup. Check whether struct usb_ep name
pointer has been set instead.
usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
- usbhsf_dma_prepare_pop_with_usb_dmac()
- usbhsf_dma_pop_done_with_usb_dmac()
So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle") Cc: <[email protected]> # v3.19+ Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
USB_GADGET_DUALSPEED was removed by commit 85b8614d7223 ("usb: gadget:
get rid of USB_GADGET_{DUAL,SUPER}SPEED"), but the USB_SNP_UDC_PLAT
symbol still selects it.
Remove the USB_GADGET_DUALSPEED select from USB_SNP_UDC_PLAT.
Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.
Jack Pham [Thu, 25 Jan 2018 07:58:20 +0000 (23:58 -0800)]
usb: gadget: f_fs: Use config_ep_by_speed()
In commit 2bfa0719ac2a ("usb: gadget: function: f_fs: pass
companion descriptor along") there is a pointer arithmetic
bug where the comp_desc is obtained as follows:
Since ds is a pointer to usb_endpoint_descriptor, adding
7 to it ends up going out of bounds (7 * sizeof(struct
usb_endpoint_descriptor), which is actually 7*9 bytes) past
the SS descriptor. As a result the maxburst value will be
read incorrectly, and the UDC driver will also get a garbage
comp_desc (assuming it uses it).
Since Felipe wrote, "Eventually, f_fs.c should be converted
to use config_ep_by_speed() like all other functions, though",
let's finally do it. This allows the other usb_ep fields to
be properly populated, such as maxpacket and mult. It also
eliminates the awkward speed-based descriptor lookup since
config_ep_by_speed() does that already using the ones found
in struct usb_function.
Jack Pham [Wed, 24 Jan 2018 08:11:53 +0000 (00:11 -0800)]
usb: gadget: f_fs: Process all descriptors during bind
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fabio Estevam [Thu, 18 Jan 2018 02:22:45 +0000 (00:22 -0200)]
usb: phy: mxs: Fix NULL pointer dereference on i.MX23/28
Commit e93650994a95 ("usb: phy: mxs: add usb charger type detection")
causes the following kernel hang on i.MX28:
[ 2.207973] usbcore: registered new interface driver usb-storage
[ 2.235659] Unable to handle kernel NULL pointer dereference at virtual address 00000188
[ 2.244195] pgd = (ptrval)
[ 2.246994] [00000188] *pgd=00000000
[ 2.250676] Internal error: Oops: 5 [#1] ARM
[ 2.254979] Modules linked in:
[ 2.258089] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc8-next-20180117-00002-g75d5f21 #7
[ 2.266724] Hardware name: Freescale MXS (Device Tree)
[ 2.271921] PC is at regmap_read+0x0/0x5c
[ 2.275977] LR is at mxs_phy_charger_detect+0x34/0x1dc
mxs_phy_charger_detect() makes accesses to the anatop registers via regmap,
however i.MX23/28 do not have such registers, which causes a NULL pointer
dereference.
Fix the issue by doing a NULL check on the 'regmap' pointer.
Manu Gautam [Thu, 18 Jan 2018 11:24:30 +0000 (16:54 +0530)]
usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode
Commit 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during
host bus-suspend/resume") updated suspend/resume routines to not
power_off and reinit PHYs/core for host mode.
It broke platforms that rely on DWC3 core to power_off PHYs to
enter low power state on system suspend.
Perform dwc3_core_exit/init only during host mode system_suspend/
resume to addresses power regression from above mentioned patch
and also allow USB session to stay connected across
runtime_suspend/resume in host mode. While at it also replace
existing checks for HOST only dr_mode with current_dr_role to
have similar core driver behavior for both Host-only and DRD+Host
configurations.
Fixes: 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume") Reviewed-by: Roger Quadros <[email protected]> Signed-off-by: Manu Gautam <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
John Keeping [Fri, 12 Jan 2018 18:43:32 +0000 (18:43 +0000)]
usb: gadget: f_uac2: fix bFirstInterface in composite gadget
If there are multiple functions associated with a configuration, then
the UAC2 interfaces may not start at zero. Set the correct first
interface number in the association descriptor so that the audio
interfaces are enumerated correctly in this case.
Thinh Nguyen [Sat, 13 Jan 2018 02:18:27 +0000 (18:18 -0800)]
usb: dwc3: ep0: Reset TRB counter for ep0 IN
DWC3 tracks TRB counter for each ep0 direction separately. In control
read transfer completion handler, the driver needs to reset the TRB
enqueue counter for ep0 IN direction. Currently the driver only resets
the TRB counter for control OUT endpoint. Check for the data direction
and properly reset the TRB counter from correct control endpoint.
Thinh Nguyen [Sat, 13 Jan 2018 02:18:05 +0000 (18:18 -0800)]
usb: dwc3: gadget: Set maxpacket size for ep0 IN
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()
This patch fixes an issue that the renesas_usb3_remove() causes
NULL pointer dereference because the usb3_to_dev() macro will use
the gadget instance and it will be deleted before.
usb: dwc3: of-simple: fix oops by unbalanced clk disable call
dwc3_of_simple_dev_pm_ops has never been used since commit a0d8c4cfdf31
("usb: dwc3: of-simple: set dev_pm_ops"), but this commit has brought
and oops when unbind the device due this sequence:
projects / linux.git / log