5.11.22-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 298/329 KVM: x86: Emulate RDPID only if RDTSCP is supported
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 85d0011264da24be08ae907d7f29983a597ca9b1 upstream.
Do not advertise emulation support for RDPID if RDTSCP is unsupported. RDPID emulation subtly relies on MSR_TSC_AUX to exist in hardware, as both vmx_get_msr() and svm_get_msr() will return an error if the MSR is unsupported, i.e. ctxt->ops->get_msr() will fail and the emulator will inject a #UD.
Note, RDPID emulation also relies on RDTSCP being enabled in the guest, but this is a KVM bug and will eventually be fixed.
Message-Id: <[email protected]>
--- arch/x86/kvm/cpuid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/kvm/cpuid.c +2 -1
@@ -573,7 +573,8 @@ static int __do_cpuid_func_emulated(strucase 7 : entry->flags |=KVM_CPUID_FLAG_SIGNIFCANT_INDEX ; entry->eax =0 ; - entry->ecx =F (RDPID ); +if (kvm_cpu_cap_has (X86_FEATURE_RDTSCP )) + entry->ecx =F (RDPID ); ++array->nent;default :break ;
Greg Kroah-Hartman
maintainerPATCH 299/329 KVM: x86: Move RDPID emulation intercept to its own enum
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 2183de4161b90bd3851ccd3910c87b2c9adfc6ed upstream.
Add a dedicated intercept enum for RDPID instead of piggybacking RDTSCP. Unlike VMX's ENABLE_RDTSCP, RDPID is not bound to SVM's RDTSCP intercept.
Message-Id: <[email protected]>
--- arch/x86/kvm/emulate.c | 2 +- arch/x86/kvm/kvm_emulate.h | 1 + arch/x86/kvm/vmx/vmx.c | 3 ++- 3 files changed, 4 insertions(+), 2 deletions(-)
arch/x86/kvm/emulate.c +1 -1
@@ -4502,7 +4502,7 @@ static const struct opcode group8[] = {* from the register case of group9. */ static const struct gprefix pfx_0f_c7_7 = { -N ,N ,N ,II (DstMem | ModRM | Op3264 | EmulateOnUD, em_rdpid, rdtscp), +N ,N ,N ,II (DstMem | ModRM | Op3264 | EmulateOnUD, em_rdpid, rdpid), };
arch/x86/kvm/kvm_emulate.h +1 -0
@@ -468,6 +468,7 @@ enum x86_intercept { x86_intercept_clgi, x86_intercept_skinit, x86_intercept_rdtscp, + x86_intercept_rdpid, x86_intercept_icebp, x86_intercept_wbinvd, x86_intercept_monitor,
arch/x86/kvm/vmx/vmx.c +2 -1
@@ -7346,8 +7346,9 @@ static int vmx_check_intercept(struct kv/* * RDPID causes #UD if disabled through secondary execution controls. * Because it is marked as EmulateOnUD, we need to intercept it here. +* Note, RDPID is hidden behind ENABLE_RDTSCP. */ -case x86_intercept_rdtscp: +case x86_intercept_rdpid:if (!nested_cpu_has2 (vmcs12,SECONDARY_EXEC_ENABLE_RDTSCP )) { exception->vector =UD_VECTOR ; exception->error_code_valid = false;
Greg Kroah-Hartman
maintainerPATCH 300/329 KVM: nVMX: Always make an attempt to map eVMCS after migration
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
commit f5c7e8425f18fdb9bdb7d13340651d7876890329 upstream.
When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request.
Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.
As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state().
Message-Id: <[email protected]>
--- arch/x86/kvm/vmx/nested.c | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-)
arch/x86/kvm/vmx/nested.c +19 -10
@@ -3140,15 +3140,8 @@ static bool nested_get_evmcs_page(structnested_vmx_handle_enlightened_vmptrld (vcpu, false);if (evmptrld_status ==EVMPTRLD_VMFAIL || - evmptrld_status ==EVMPTRLD_ERROR ) { -pr_debug_ratelimited ("%s: enlightened vmptrld failed\n" , - __func__); - vcpu->run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; - vcpu->run->internal.suberror = -KVM_INTERNAL_ERROR_EMULATION ; - vcpu->run->internal.ndata =0 ; + evmptrld_status ==EVMPTRLD_ERROR )return false; - } }return true;
@@ -3236,8 +3229,16 @@ static bool nested_get_vmcs12_pages(strustatic bool vmx_get_nested_state_pages (struct kvm_vcpu *vcpu) { -if (!nested_get_evmcs_page (vcpu)) +if (!nested_get_evmcs_page (vcpu)) { +pr_debug_ratelimited ("%s: enlightened vmptrld failed\n" , + __func__); + vcpu->run->exit_reason =KVM_EXIT_INTERNAL_ERROR ; + vcpu->run->internal.suberror = +KVM_INTERNAL_ERROR_EMULATION ; + vcpu->run->internal.ndata =0 ; +return false; + }if (is_guest_mode (vcpu) && !nested_get_vmcs12_pages (vcpu))return false;
@@ -4467,7 +4468,15 @@ void nested_vmx_vmexit(struct kvm_vcpu */* trying to cancel vmlaunch/vmresume is a bug */ WARN_ON_ONCE (vmx->nested.nested_run_pending); -kvm_clear_request (KVM_REQ_GET_NESTED_STATE_PAGES , vcpu); +if (kvm_check_request (KVM_REQ_GET_NESTED_STATE_PAGES , vcpu)) { +/* +* KVM_REQ_GET_NESTED_STATE_PAGES is also used to map +* Enlightened VMCS after migration and we still need to +* do that when something is forcing L2->L1 exit prior to +* the first L2 run. +*/ + (void )nested_get_evmcs_page (vcpu); + }/* Service the TLB flush request for L2 before switching to L1. */ if (kvm_check_request (KVM_REQ_TLB_FLUSH_CURRENT , vcpu))
Greg Kroah-Hartman
maintainerPATCH 301/329 KVM: VMX: Do not advertise RDPID if ENABLE_RDTSCP control is unsupported
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 8aec21c04caa2000f91cf8822ae0811e4b0c3971 upstream.
Clear KVM's RDPID capability if the ENABLE_RDTSCP secondary exec control is unsupported. Despite being enumerated in a separate CPUID flag, RDPID is bundled under the same VMCS control as RDTSCP and will #UD in VMX non-root if ENABLE_RDTSCP is not enabled.
Message-Id: <[email protected]>
--- arch/x86/kvm/vmx/vmx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx/vmx.c +4 -2
@@ -7288,9 +7288,11 @@ static __init void vmx_set_cpu_caps(voidif (!cpu_has_vmx_xsaves ())kvm_cpu_cap_clear (X86_FEATURE_XSAVES ); -/* CPUID 0x80000001 */ -if (!cpu_has_vmx_rdtscp ()) +/* CPUID 0x80000001 and 0x7 (RDPID) */ +if (!cpu_has_vmx_rdtscp ()) {kvm_cpu_cap_clear (X86_FEATURE_RDTSCP ); +kvm_cpu_cap_clear (X86_FEATURE_RDPID ); + }if (cpu_has_vmx_waitpkg ())kvm_cpu_cap_check_and_set (X86_FEATURE_WAITPKG );
Greg Kroah-Hartman
maintainerPATCH 302/329 KVM: VMX: Disable preemption when probing user return MSRs
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 5104d7ffcf24749939bea7fdb5378d186473f890 upstream.
Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU.
Opportunistically land the helper in common x86, SVM will use the helper in a future commit.
Message-Id: <[email protected]>
--- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/vmx/vmx.c | 5 +---- arch/x86/kvm/x86.c | 16 ++++++++++++++++ 3 files changed, 18 insertions(+), 4 deletions(-)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -1694,6 +1694,7 @@ int kvm_pv_send_ipi(struct kvm *kvm, uns unsigned long icr, int op_64_bit);void kvm_define_user_return_msr (unsigned index,u32 msr); +int kvm_probe_user_return_msr (u32 msr);int kvm_set_user_return_msr (unsigned index,u64 val,u64 mask);u64 kvm_scale_tsc (struct kvm_vcpu *vcpu,u64 tsc);
arch/x86/kvm/vmx/vmx.c +1 -4
@@ -6850,12 +6850,9 @@ static int vmx_create_vcpu(struct kvm_vcfor (i =0 ; i <ARRAY_SIZE (vmx_uret_msrs_list); ++i) {u32 index = vmx_uret_msrs_list[i]; -u32 data_low, data_high;int j = vmx->nr_uret_msrs; -if (rdmsr_safe (index, &data_low, &data_high) <0 ) -continue ; -if (wrmsr_safe (index, data_low, data_high) <0 ) +if (kvm_probe_user_return_msr (index))continue ; vmx->guest_uret_msrs[j].slot = i;
arch/x86/kvm/x86.c +16 -0
@@ -323,6 +323,22 @@ static void kvm_on_user_return(struct us } } +int kvm_probe_user_return_msr (u32 msr) +{ +u64 val; +int ret; + +preempt_disable (); + ret =rdmsrl_safe (msr, &val); +if (ret) + goto out; + ret =wrmsrl_safe (msr, val); +out: +preempt_enable (); +return ret; +} +EXPORT_SYMBOL_GPL (kvm_probe_user_return_msr); +void kvm_define_user_return_msr (unsigned slot,u32 msr) {BUG_ON (slot >=KVM_MAX_NR_USER_RETURN_MSRS );
Greg Kroah-Hartman
maintainerPATCH 303/329 mm: fix struct page layout on 32-bit systems
In reply to Greg Kroah-HartmanFrom: Matthew Wilcox (Oracle) <[email protected]>
commit 9ddb3c14afba8bc5950ed297f02d4ae05ff35cd1 upstream.
32-bit architectures which expect 8-byte alignment for 8-byte integers and need 64-bit DMA addresses (arm, mips, ppc) had their struct page inadvertently expanded in 2019. When the dma_addr_t was added, it forced the alignment of the union to 8 bytes, which inserted a 4 byte gap between 'flags' and the union.
Fix this by storing the dma_addr_t in one or two adjacent unsigned longs. This restores the alignment to that of an unsigned long. We always store the low bits in the first word to prevent the PageTail bit from being inadvertently set on a big endian platform. If that happened, get_user_pages_fast() racing against a page which was freed and reallocated to the page_pool could dereference a bogus compound_head(), which would be hard to trace back to this cause.
--- include/linux/mm_types.h | 4 ++-- include/net/page_pool.h | 12 +++++++++++- net/core/page_pool.c | 12 +++++++----- 3 files changed, 20 insertions(+), 8 deletions(-)
include/linux/mm_types.h +2 -2
@@ -97,10 +97,10 @@ struct page { };struct {/* page_pool used by netstack */ /** -* @dma_addr: might require a 64-bit value even on +* @dma_addr: might require a 64-bit value on * 32-bit architectures. */ -dma_addr_t dma_addr; +unsigned long dma_addr[2 ]; }; struct { /* slab, slob and slub */ union {
include/net/page_pool.h +11 -1
@@ -198,7 +198,17 @@ static inline void page_pool_recycle_dirstatic inline dma_addr_t page_pool_get_dma_addr (struct page *page) { -return page->dma_addr; +dma_addr_t ret = page->dma_addr[0 ]; +if (sizeof (dma_addr_t) >sizeof (unsigned long )) + ret |= (dma_addr_t )page->dma_addr[1 ] <<16 <<16 ; +return ret; +} + +static inline void page_pool_set_dma_addr (struct page *page,dma_addr_t addr) +{ + page->dma_addr[0 ] = addr; +if (sizeof (dma_addr_t) >sizeof (unsigned long )) + page->dma_addr[1 ] =upper_32_bits (addr); }static inline bool is_page_pool_compiled_in (void )
net/core/page_pool.c +7 -5
@@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_devicstruct page *page, unsigned int dma_sync_size) { + dma_addr_t dma_addr = page_pool_get_dma_addr(page); + dma_sync_size =min (dma_sync_size, pool->p.max_len); -dma_sync_single_range_for_device (pool->p.dev, page->dma_addr, +dma_sync_single_range_for_device (pool->p.dev, dma_addr, pool->p.offset, dma_sync_size, pool->p.dma_dir); }
@@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_paput_page (page);return NULL ; } - page->dma_addr = dma; +page_pool_set_dma_addr (page, dma);if (pool->p.flags &PP_FLAG_DMA_SYNC_DEV )page_pool_dma_sync_for_device (pool, page, pool->p.max_len);
@@ -294,13 +296,13 @@ void page_pool_release_page(struct page_*/ goto skip_dma_unmap; - dma = page->dma_addr; + dma =page_pool_get_dma_addr (page); -/* When page is unmapped, it cannot be returned our pool */ +/* When page is unmapped, it cannot be returned to our pool */ dma_unmap_page_attrs (pool->p.dev, dma,PAGE_SIZE << pool->p.order, pool->p.dma_dir,DMA_ATTR_SKIP_CPU_SYNC ); - page->dma_addr =0 ; +page_pool_set_dma_addr (page,0 ); skip_dma_unmap:/* This may be the last page returned, releasing the pool, so * it is not safe to reference pool afterwards.
Greg Kroah-Hartman
maintainerPATCH 304/329 MIPS: Reinstate platform `__div64_32 handler
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit c49f71f60754acbff37505e1d16ca796bf8a8140 upstream.
Our current MIPS platform __div64_32' handler is inactive, because it is incorrectly only enabled for 64-bit configurations, for which generic do_div' code does not call it anyway.
The handler is not suitable for being called from there though as it only calculates 32 bits of the quotient under the assumption the 64-bit divident has been suitably reduced. Code for such reduction used to be there, however it has been incorrectly removed with commit c21004cd5b4c ("MIPS: Rewrite <asm/div64.h> to work with gcc 4.4.0."), which should have only updated an obsoleted constraint for an inline asm involving $hi and $lo register outputs, while possibly wiring the original MIPS variant of the do_div' macro as __div64_32' handler for the generic `do_div' implementation
Correct the handler as follows then:
- Revert most of the commit referred, however retaining the current formatting, except for the final two instructions of the inline asm sequence, which the original commit missed. Omit the original 64-bit parts though.
- Rename the original do_div' macro to __div64_32'. Use the combined x' constraint referring to the MD accumulator as a whole, replacing the original individual h' and l' constraints used for $hi and $lo registers respectively, of which h' has been obsoleted with GCC 4.4. Update surrounding code accordingly.
We have since removed support for GCC versions before 4.9, so no need for a special arrangement here; GCC has supported the `x' constraint since forever anyway, or at least going back to 1991.
- Rename the __base' local variable in __div64_32' to __radix' to avoid a conflict with a local variable in do_div'.
- Actually enable this code for 32-bit rather than 64-bit configurations by qualifying it with BITS_PER_LONG being 32 instead of 64. Include <asm/bitsperlong.h> for this macro rather than <linux/types.h> as we don't need anything else.
- Finally include <asm-generic/div64.h> last rather than first.
This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0668s and 0.2629s from 2.1529s and 0.5647s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. For a reference 64-bit `do_div' code where we have the DDIVU instruction available to do the whole calculation right away averages at 0.0660s for the latter CPU.
--- arch/mips/include/asm/div64.h | 57 ++++++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 16 deletions(-)
arch/mips/include/asm/div64.h +41 -16
@@ -1,5 +1,5 @@/* -* Copyright (C) 2000, 2004 Maciej W. Rozycki +* Copyright (C) 2000, 2004, 2021 Maciej W. Rozycki * Copyright (C) 2003, 07 Ralf Baechle ([email protected]) * * This file is subject to the terms and conditions of the GNU General Public
@@ -9,25 +9,18 @@#ifndef __ASM_DIV64_H#define __ASM_DIV64_H -#include <asm-generic/div64.h> - -#if BITS_PER_LONG ==64 +#include <asm/bitsperlong.h> -#include <linux/types.h> +#if BITS_PER_LONG ==32 /* * No traps on overflows for any of these... */ -#define __div64_32 (n, base) \ -({ \ +#define do_div64_32 (res, high, low, base) ({ \ unsigned long __cf, __tmp, __tmp2, __i; \ unsigned long __quot32, __mod32; \ - unsigned long __high, __low; \ - unsigned long long __n; \ \ - __high = *__n >> 32; \ - __low = __n; \ __asm__( \ " .set push \n" \ " .set noat \n" \
@@ -51,18 +44,50 @@" subu %0, %0, %z6 \n" \" addiu %2, %2, 1 \n" \"3: \n" \ - " bnez %4, 0b\n\t" \ - " srl %5, %1, 0x1f\n\t" \ +" bnez %4, 0b \n" \ +" srl %5, %1, 0x1f \n" \" .set pop" \ : "=&r" (__mod32), "=&r" (__tmp), \ "=&r" (__quot32), "=&r" (__cf), \ "=&r" (__i), "=&r" (__tmp2) \ - : "Jr" (base), "0" (__high), "1" (__low)); \ + : "Jr" (base), "0" (high), "1" (low)); \ \ - (__n) = __quot32; \ + (res) = __quot32; \ __mod32; \ }) -#endif /* BITS_PER_LONG == 64 */ +#define __div64_32(n, base) ({ \ +unsigned long __upper, __low, __high, __radix; \ +unsigned long long __modquot; \ +unsigned long long __quot; \ +unsigned long long __div; \ +unsigned long __mod; \ + \ + __div = (*n); \ + __radix = (base); \ + \ + __high = __div >>32 ; \ + __low = __div; \ + __upper = __high; \ + \ +if (__high) { \ + __asm__("divu $0, %z1, %z2" \ + :"=x" (__modquot) \ + :"Jr" (__high),"Jr" (__radix)); \ + __upper = __modquot >>32 ; \ + __high = __modquot; \ + } \ + \ + __mod =do_div64_32 (__low, __upper, __low, __radix); \ + \ + __quot = __high; \ + __quot = __quot <<32 | __low; \ + (*n) = __quot; \ + __mod; \ +}) + +#endif /* BITS_PER_LONG == 32 */ + +#include <asm-generic/div64.h> #endif /* __ASM_DIV64_H */
Greg Kroah-Hartman
maintainerPATCH 305/329 MIPS: Avoid DIVU in `__div64_32 is result would be zero
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit c1d337d45ec0a802299688e17d568c4e3a585895 upstream.
We already check the high part of the divident against zero to avoid the costly DIVU instruction in that case, needed to reduce the high part of the divident, so we may well check against the divisor instead and set the high part of the quotient to zero right away. We need to treat the high part the divident in that case though as the remainder that would be calculated by the DIVU instruction we avoided.
This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0445s and 0.2619s from 1.0668s and 0.2629s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz.
--- arch/mips/include/asm/div64.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/mips/include/asm/div64.h +4 -2
@@ -68,9 +68,11 @@ \ __high = __div >>32 ; \ __low = __div; \ - __upper = __high; \ \ -if (__high) { \ +if (__high < __radix) { \ + __upper = __high; \ + __high =0 ; \ + }else { \ __asm__("divu $0, %z1, %z2" \ :"=x" (__modquot) \ :"Jr" (__high),"Jr" (__radix)); \
Greg Kroah-Hartman
maintainerPATCH 306/329 MIPS: Avoid handcoded DIVU in `__div64_32 altogether
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit 25ab14cbe9d1b66fda44c71a2db7582a31b6f5cd upstream.
Remove the inline asm with a DIVU instruction from `__div64_32' and use plain C code for the intended DIVMOD calculation instead. GCC is smart enough to know that both the quotient and the remainder are calculated with single DIVU, so with ISAs up to R5 the same instruction is actually produced with overall similar code.
For R6 compiled code will work, but separate DIVU and MODU instructions will be produced, which are also interlocked, so scalar implementations will likely not perform as well as older ISAs with their asynchronous MD unit. Likely still faster then the generic algorithm though.
This removes a compilation error for R6 however where the original DIVU instruction is not supported anymore and the MDU accumulator registers have been removed and consequently GCC complains as to a constraint it cannot find a register for:
In file included from ./include/linux/math.h:5,
from ./include/linux/kernel.h:13,
from mm/page-writeback.c:15:
./include/linux/math64.h: In function 'div_u64_rem':
./arch/mips/include/asm/div64.h:76:17: error: inconsistent operand constraints in an 'asm'
76 | __asm__("divu $0, %z1, %z2" \
| ^~~~~~~
./include/asm-generic/div64.h:245:25: note: in expansion of macro '__div64_32'
245 | __rem = __div64_32(&(n), __base); \
| ^~~~~~~~~~./include/linux/math64.h:91:22: note: in expansion of macro 'do_div'
91 | *remainder = do_div(dividend, divisor);
| ^~~~~~
This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0404s from 1.0445s with R3400 @40MHz. The module's MIPS I machine code has also shrunk by 12 bytes or 3 instructions.
--- arch/mips/include/asm/div64.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
arch/mips/include/asm/div64.h +2 -6
@@ -58,7 +58,6 @@#define __div64_32 (n, base) ({ \ unsigned long __upper, __low, __high, __radix; \ - unsigned long long __modquot; \ unsigned long long __quot; \ unsigned long long __div; \ unsigned long __mod; \
@@ -73,11 +72,8 @@ __upper = __high; \ __high =0 ; \ }else { \ - __asm__("divu $0, %z1, %z2" \ - :"=x" (__modquot) \ - :"Jr" (__high),"Jr" (__radix)); \ - __upper = __modquot >>32 ; \ - __high = __modquot; \ + __upper = __high % __radix; \ + __high /= __radix; \ } \ \ __mod =do_div64_32 (__low, __upper, __low, __radix); \
Greg Kroah-Hartman
maintainerPATCH 307/329 clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
In reply to Greg Kroah-HartmanFrom: Tony Lindgren <[email protected]>
commit 3efe7a878a11c13b5297057bfc1e5639ce1241ce upstream.
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days.
To work around the issue, we need to use timer-ti-dm timers instead.
Let's prepare for adding support for percpu timers by adding a common dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). This patch makes no intentional functional changes.
--- drivers/clocksource/timer-ti-dm-systimer.c | 68 ++++++++++++++++++----------- 1 file changed, 44 insertions(+), 24 deletions(-)
drivers/clocksource/timer-ti-dm-systimer.c +44 -24
@@ -530,17 +530,17 @@ static void omap_clockevent_unidle(strucwritel_relaxed (OMAP_TIMER_INT_OVERFLOW , t->base + t->wakeup); } -static int __init dmtimer_clockevent_init (struct device_node *np) +static int __init dmtimer_clkevt_init_common (struct dmtimer_clockevent *clkevt, +struct device_node *np, +unsigned int features, +const struct cpumask *cpumask, +const char *name, +int rating) { -struct dmtimer_clockevent *clkevt;struct clock_event_device *dev;struct dmtimer_systimer *t;int error; - clkevt =kzalloc (sizeof (*clkevt),GFP_KERNEL ); -if (!clkevt) -return -ENOMEM ; - t = &clkevt->t; dev = &clkevt->dev;
@@ -548,25 +548,23 @@ static int __init dmtimer_clockevent_ini* We mostly use cpuidle_coupled with ARM local timers for runtime, * so there's probably no use for CLOCK_EVT_FEAT_DYNIRQ here. */ - dev->features =CLOCK_EVT_FEAT_PERIODIC |CLOCK_EVT_FEAT_ONESHOT ; - dev->rating =300 ; + dev->features = features; + dev->rating = rating; dev->set_next_event = dmtimer_set_next_event; dev->set_state_shutdown = dmtimer_clockevent_shutdown; dev->set_state_periodic = dmtimer_set_periodic; dev->set_state_oneshot = dmtimer_clockevent_shutdown; dev->set_state_oneshot_stopped = dmtimer_clockevent_shutdown; dev->tick_resume = dmtimer_clockevent_shutdown; - dev->cpumask = cpu_possible_mask; + dev->cpumask = cpumask; dev->irq =irq_of_parse_and_map (np,0 ); -if (!dev->irq) { - error = -ENXIO ; - goto err_out_free; - } +if (!dev->irq) +return -ENXIO ; error =dmtimer_systimer_setup (np, &clkevt->t);if (error) - goto err_out_free; +return error; clkevt->period =0xffffffff -DIV_ROUND_CLOSEST (t->rate,HZ );
@@ -578,32 +576,54 @@ static int __init dmtimer_clockevent_iniwritel_relaxed (OMAP_TIMER_CTRL_POSTED , t->base + t->ifctrl); error =request_irq (dev->irq, dmtimer_clockevent_interrupt, -IRQF_TIMER ,"clockevent" , clkevt); +IRQF_TIMER , name, clkevt);if (error) goto err_out_unmap;writel_relaxed (OMAP_TIMER_INT_OVERFLOW , t->base + t->irq_ena);writel_relaxed (OMAP_TIMER_INT_OVERFLOW , t->base + t->wakeup); -pr_info ("TI gptimer clockevent: %s%lu Hz at %pOF\n" , -of_find_property (np,"ti,timer-alwon" ,NULL ) ? +pr_info ("TI gptimer %s: %s%lu Hz at %pOF\n" , + name,of_find_property (np,"ti,timer-alwon" ,NULL ) ?"always-on " :"" , t->rate, np->parent); -clockevents_config_and_register (dev, t->rate, -3 ,/* Timer internal resynch latency */ +return 0 ; + +err_out_unmap: +iounmap (t->base); + +return error; +} + +static int __init dmtimer_clockevent_init (struct device_node *np) +{ +struct dmtimer_clockevent *clkevt; +int error; + + clkevt =kzalloc (sizeof (*clkevt),GFP_KERNEL ); +if (!clkevt) +return -ENOMEM ; + + error =dmtimer_clkevt_init_common (clkevt, np, +CLOCK_EVT_FEAT_PERIODIC | +CLOCK_EVT_FEAT_ONESHOT , + cpu_possible_mask,"clockevent" , +300 ); +if (error) + goto err_out_free; + +clockevents_config_and_register (&clkevt->dev, clkevt->t.rate, +3 ,/* Timer internal resync latency */ 0xffffffff );if (of_machine_is_compatible ("ti,am33xx" ) ||of_machine_is_compatible ("ti,am43" )) { - dev->suspend = omap_clockevent_idle; - dev->resume = omap_clockevent_unidle; + clkevt->dev.suspend = omap_clockevent_idle; + clkevt->dev.resume = omap_clockevent_unidle; }return 0 ; -err_out_unmap: -iounmap (t->base); - err_out_free:kfree (clkevt);
Greg Kroah-Hartman
maintainerPATCH 308/329 clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940
In reply to Greg Kroah-HartmanFrom: Tony Lindgren <[email protected]>
commit 25de4ce5ed02994aea8bc111d133308f6fd62566 upstream.
There is a timer wrap issue on dra7 for the ARM architected timer. In a typical clock configuration the timer fails to wrap after 388 days.
To work around the issue, we need to use timer-ti-dm percpu timers instead.
Let's configure dmtimer3 and 4 as percpu timers by default, and warn about the issue if the dtb is not configured properly.
Let's do this as a single patch so it can be backported to v5.8 and later kernels easily. Note that this patch depends on earlier timer-ti-dm systimer posted mode fixes, and a preparatory clockevent patch "clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue".
For more information, please see the errata for "AM572x Sitara Processors Silicon Revisions 1.1, 2.0":
https://www.ti.com/lit/er/sprz429m/sprz429m.pdf
The concept is based on earlier reference patches done by Tero Kristo and Keerthy.
--- arch/arm/boot/dts/dra7-l4.dtsi | 4 - arch/arm/boot/dts/dra7.dtsi | 20 +++++++ drivers/clocksource/timer-ti-dm-systimer.c | 76 +++++++++++++++++++++++++++++ include/linux/cpuhotplug.h | 1 4 files changed, 99 insertions(+), 2 deletions(-)
arch/arm/boot/dts/dra7-l4.dtsi +2 -2
@@ -1168,7 +1168,7 @@ }; }; - target-module@34000 { /* 0x48034000, ap 7 46.0 */ + timer3_target: target-module@34000 { /* 0x48034000, ap 7 46.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x34000 0x4>, <0x34010 0x4>;
@@ -1195,7 +1195,7 @@ }; }; - target-module@36000 { /* 0x48036000, ap 9 4e.0 */ + timer4_target: target-module@36000 { /* 0x48036000, ap 9 4e.0 */ compatible = "ti,sysc-omap4-timer", "ti,sysc"; reg = <0x36000 0x4>, <0x36010 0x4>;
arch/arm/boot/dts/dra7.dtsi +20 -0
@@ -46,6 +46,7 @@ timer { compatible = "arm,armv7-timer"; + status = "disabled"; /* See ARM architected timer wrap erratum i940 */ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>, <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>, <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
@@ -1241,3 +1242,22 @@ assigned-clock-parents = <&sys_32k_ck>; }; }; + +/* Local timers, see ARM architected timer wrap erratum i940 */ +&timer3_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <&l4per_clkctrl DRA7_L4PER_TIMER3_CLKCTRL 24>; + assigned-clock-parents = <&timer_sys_clk_div>; + }; +}; + +&timer4_target { + ti,no-reset-on-init; + ti,no-idle; + timer@0 { + assigned-clocks = <&l4per_clkctrl DRA7_L4PER_TIMER4_CLKCTRL 24>; + assigned-clock-parents = <&timer_sys_clk_div>; + }; +};
drivers/clocksource/timer-ti-dm-systimer.c +76 -0
94 lines not on this page · raw message
include/linux/cpuhotplug.h +1 -0
@@ -135,6 +135,7 @@ enum cpuhp_state {CPUHP_AP_RISCV_TIMER_STARTING ,CPUHP_AP_CLINT_TIMER_STARTING ,CPUHP_AP_CSKY_TIMER_STARTING , +CPUHP_AP_TI_GP_TIMER_STARTING ,CPUHP_AP_HYPERV_TIMER_STARTING ,CPUHP_AP_KVM_STARTING , CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
Greg Kroah-Hartman
maintainerPATCH 309/329 usb: typec: tcpm: Fix error while calculating PPS out values
In reply to Greg Kroah-HartmanFrom: Badhri Jagan Sridharan <[email protected]>
commit 374157ff88ae1a7f7927331cbc72c1ec11994e8a upstream.
"usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply" introduced a regression for req_out_volt and req_op_curr calculation.
req_out_volt should consider the newly calculated max voltage instead of previously accepted max voltage by the port partner. Likewise, req_op_curr should consider the newly calculated max current instead of previously accepted max current by the port partner.
--- drivers/usb/typec/tcpm/tcpm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +3 -3
@@ -2546,10 +2546,10 @@ static unsigned int tcpm_pd_select_pps_a port->pps_data.req_max_volt =min (pdo_pps_apdo_max_voltage (src),pdo_pps_apdo_max_voltage (snk)); port->pps_data.req_max_curr =min_pps_apdo_current (src, snk); - port->pps_data.req_out_volt =min (port->pps_data.max_volt, -max (port->pps_data.min_volt, + port->pps_data.req_out_volt =min (port->pps_data.req_max_volt, +max (port->pps_data.req_min_volt, port->pps_data.req_out_volt)); - port->pps_data.req_op_curr =min (port->pps_data.max_curr, + port->pps_data.req_op_curr =min (port->pps_data.req_max_curr, port->pps_data.req_op_curr); }
Greg Kroah-Hartman
maintainerPATCH 310/329 kobject_uevent: remove warning in init_uevent_argv()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
commit b4104180a2efb85f55e1ba1407885c9421970338 upstream.
syzbot can trigger the WARN() in init_uevent_argv() which isn't the nicest as the code does properly recover and handle the error. So change the WARN() call to pr_warn() and provide some more information on what the buffer size that was needed.
--- lib/kobject_uevent.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
lib/kobject_uevent.c +5 -4
@@ -251,12 +251,13 @@ static int kobj_usermode_filter(struct kstatic int init_uevent_argv (struct kobj_uevent_env *env,const char *subsystem) { +int buffer_size =sizeof (env->buf) - env->buflen;int len; - len =strlcpy (&env->buf[env->buflen], subsystem, -sizeof (env->buf) - env->buflen); -if (len >= (sizeof (env->buf) - env->buflen)) { -WARN (1 ,KERN_ERR "init_uevent_argv: buffer size too small\n" ); + len =strlcpy (&env->buf[env->buflen], subsystem, buffer_size); +if (len >= buffer_size) { +pr_warn ("init_uevent_argv: buffer size of %d too small, needed %d\n" , + buffer_size, len);return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 311/329 drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp
In reply to Greg Kroah-HartmanFrom: Lv Yunlong <[email protected]>
commit ea995218dddba171fecd05496c69617c5ef3c5b8 upstream.
Our code analyzer reported a double free bug.
In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base is freed by i915_gem_object_put() with a reference dropped. Then free_pd calls free_px() defined in intel_ppgtt.c, which calls i915_gem_object_put() to put pde->pt.base again.
As pde->pt.base is protected by refcount, so the second put will not free pde->pt.base actually. But, maybe it is better to remove the first put?
--- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 - 1 file changed, 1 deletion(-)
drivers/gpu/drm/i915/gt/gen8_ppgtt.c +0 -1
@@ -631,7 +631,6 @@ static int gen8_preallocate_top_level_pd err =pin_pt_dma (vm, pde->pt.base);if (err) { -i915_gem_object_put (pde->pt.base);free_pd (vm, pde);return err; }
Greg Kroah-Hartman
maintainerPATCH 312/329 drm/msm/dp: check sink_count before update is_connected status
In reply to Greg Kroah-HartmanFrom: Kuogee Hsieh <[email protected]>
commit d9aa6571b28ba0022de1e48801ff03a1854c7ef2 upstream.
Link status is different from display connected status in the case of something like an Apple dongle where the type-c plug can be connected, and therefore the link is connected, but no sink is connected until an HDMI cable is plugged into the dongle. The sink_count of DPCD of dongle will increase to 1 once an HDMI cable is plugged into the dongle so that display connected status will become true. This checking also apply at pm_resume.
Changes in v4:
-- none
--- drivers/gpu/drm/msm/dp/dp_display.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/gpu/drm/msm/dp/dp_display.c +8 -7
@@ -595,10 +595,8 @@ static int dp_connect_pending_timeout(stmutex_lock (&dp->event_mutex); state = dp->hpd_state; -if (state ==ST_CONNECT_PENDING ) { -dp_display_enable (dp,0 ); +if (state ==ST_CONNECT_PENDING ) dp->hpd_state =ST_CONNECTED ; - }mutex_unlock (&dp->event_mutex);
@@ -677,10 +675,8 @@ static int dp_disconnect_pending_timeoutmutex_lock (&dp->event_mutex); state = dp->hpd_state; -if (state ==ST_DISCONNECT_PENDING ) { -dp_display_disable (dp,0 ); +if (state ==ST_DISCONNECT_PENDING ) dp->hpd_state =ST_DISCONNECTED ; - }mutex_unlock (&dp->event_mutex);
@@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *d status =dp_catalog_link_is_connected (dp->catalog); -if (status) +/* +* can not declared display is connected unless +* HDMI cable is plugged in and sink_count of +* dongle become 1 +*/ +if (status && dp->link->sink_count) dp->dp_display.is_connected = true;else dp->dp_display.is_connected = false;
Greg Kroah-Hartman
maintainerPATCH 313/329 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again
In reply to Greg Kroah-HartmanFrom: Ville Syrjälä <[email protected]>
commit 04d019961fd15de92874575536310243a0d4c5c5 upstream.
We've defined C0DRB3/C1DRB3 as 16 bit registers, so access them as such.
--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c +2 -2
@@ -652,8 +652,8 @@ static void detect_bit_6_swizzle(struct* banks of memory are paired and unswizzled on the * uneven portion, so leave that as unknown. */ -if (intel_uncore_read (uncore,C0DRB3 ) == -intel_uncore_read (uncore,C1DRB3 )) { +if (intel_uncore_read16 (uncore,C0DRB3 ) == +intel_uncore_read16 (uncore,C1DRB3 )) { swizzle_x =I915_BIT_6_SWIZZLE_9_10 ; swizzle_y =I915_BIT_6_SWIZZLE_9 ; }
Greg Kroah-Hartman
maintainerPATCH 314/329 drm/i915/overlay: Fix active retire callback alignment
In reply to Greg Kroah-HartmanFrom: Tvrtko Ursulin <[email protected]>
commit a915fe5e9601c632417ef5261af70788d7d23a8a upstream.
__i915_active_call annotation is required on the retire callback to ensure correct function alignment.
--- drivers/gpu/drm/i915/display/intel_overlay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_overlay.c +1 -1
@@ -382,7 +382,7 @@ static void intel_overlay_off_tail(struci830_overlay_clock_gating (dev_priv, true); } -static void +__i915_active_call static voidintel_overlay_last_flip_retire (struct i915_active *active) { struct intel_overlay *overlay =
Greg Kroah-Hartman
maintainerPATCH 315/329 drm/i915: Fix crash in auto_retire
In reply to Greg Kroah-HartmanFrom: Stéphane Marchesin <[email protected]>
commit 402be8a101190969fc7ff122d07e262df86e132b upstream.
The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this:
2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring kfifo_buf industrialio cros_ec_sensorhub 2021-04-24T18:03:53.804337Z WARNING kernel: [ 516.876972] cdc_ether usbnet iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev 2021-04-24T18:03:53.804337Z EMERG kernel: [ 516.879169] gsmi: Log Shutdown Reason 0x03
This change fixes this by aligning the function.
--- drivers/gpu/drm/i915/i915_active.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_active.c +2 -1
@@ -1159,7 +1159,8 @@ static int auto_active(struct i915_activreturn 0 ; } -static void auto_retire (struct i915_active *ref) +__i915_active_call static void +auto_retire (struct i915_active *ref) {i915_active_put (ref); }
Greg Kroah-Hartman
maintainerPATCH 316/329 clk: exynos7: Mark aclk_fsys1_200 as critical
In reply to Greg Kroah-HartmanFrom: Paweł Chmiel <[email protected]>
commit 34138a59b92c1a30649a18ec442d2e61f3bc34dd upstream.
This clock must be always enabled to allow access to any registers in fsys1 CMU. Until proper solution based on runtime PM is applied (similar to what was done for Exynos5433), mark that clock as critical so it won't be disabled.
It was observed on Samsung Galaxy S6 device (based on Exynos7420), where UFS module is probed before pmic used to power that device. In this case defer probe was happening and that clock was disabled by UFS driver, causing whole boot to hang on next CMU access.
--- drivers/clk/samsung/clk-exynos7.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/clk/samsung/clk-exynos7.c +6 -1
@@ -537,8 +537,13 @@ static const struct samsung_gate_clock tGATE (CLK_ACLK_FSYS0_200 ,"aclk_fsys0_200" ,"dout_aclk_fsys0_200" ,ENABLE_ACLK_TOP13 ,28 ,CLK_SET_RATE_PARENT |CLK_IS_CRITICAL ,0 ), +/* +* This clock is required for the CMU_FSYS1 registers access, keep it +* enabled permanently until proper runtime PM support is added. +*/ GATE (CLK_ACLK_FSYS1_200 ,"aclk_fsys1_200" ,"dout_aclk_fsys1_200" , -ENABLE_ACLK_TOP13 ,24 ,CLK_SET_RATE_PARENT ,0 ), +ENABLE_ACLK_TOP13 ,24 ,CLK_SET_RATE_PARENT | +CLK_IS_CRITICAL ,0 ), GATE(CLK_SCLK_PHY_FSYS1_26M, "sclk_phy_fsys1_26m", "dout_sclk_phy_fsys1_26m", ENABLE_SCLK_TOP1_FSYS11,
Greg Kroah-Hartman
maintainerPATCH 317/329 soc: mediatek: pm-domains: Add a meaningful power domain name
In reply to Greg Kroah-HartmanFrom: Enric Balletbo i Serra <[email protected]>
commit 022b02b4505ecea5eda02b18683531e49f7d8eb7 upstream.
Add the power domains names to the power domain struct so we have meaningful name for every power domain. This also removes the following debugfs error message.
[ 2.242068] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.249949] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! [ 2.257784] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present! ...
--- drivers/soc/mediatek/mt8173-pm-domains.h | 10 ++++++++++ drivers/soc/mediatek/mtk-pm-domains.c | 6 +++++- drivers/soc/mediatek/mtk-pm-domains.h | 2 ++ 3 files changed, 17 insertions(+), 1 deletion(-)
drivers/soc/mediatek/mt8173-pm-domains.h +10 -0
@@ -12,24 +12,28 @@static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = { [MT8173_POWER_DOMAIN_VDEC ] = { + .name ="vdec" , .sta_mask =PWR_STATUS_VDEC , .ctl_offs =SPM_VDE_PWR_CON , .sram_pdn_bits =GENMASK (11 ,8 ), .sram_pdn_ack_bits =GENMASK (12 ,12 ), }, [MT8173_POWER_DOMAIN_VENC ] = { + .name ="venc" , .sta_mask =PWR_STATUS_VENC , .ctl_offs =SPM_VEN_PWR_CON , .sram_pdn_bits =GENMASK (11 ,8 ), .sram_pdn_ack_bits =GENMASK (15 ,12 ), }, [MT8173_POWER_DOMAIN_ISP ] = { + .name ="isp" , .sta_mask =PWR_STATUS_ISP , .ctl_offs =SPM_ISP_PWR_CON , .sram_pdn_bits =GENMASK (11 ,8 ), .sram_pdn_ack_bits =GENMASK (13 ,12 ), }, [MT8173_POWER_DOMAIN_MM ] = { + .name ="mm" , .sta_mask =PWR_STATUS_DISP , .ctl_offs =SPM_DIS_PWR_CON , .sram_pdn_bits =GENMASK (11 ,8 ),
@@ -40,18 +44,21 @@ static const struct scpsys_domain_data s }, }, [MT8173_POWER_DOMAIN_VENC_LT] = { + .name = "venc_lt", .sta_mask = PWR_STATUS_VENC_LT, .ctl_offs = SPM_VEN2_PWR_CON, .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), }, [MT8173_POWER_DOMAIN_AUDIO] = { + .name = "audio", .sta_mask = PWR_STATUS_AUDIO, .ctl_offs = SPM_AUDIO_PWR_CON, .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(15, 12), }, [MT8173_POWER_DOMAIN_USB] = { + .name = "usb", .sta_mask = PWR_STATUS_USB, .ctl_offs = SPM_USB_PWR_CON, .sram_pdn_bits = GENMASK(11, 8),
@@ -59,18 +66,21 @@ static const struct scpsys_domain_data s .caps = MTK_SCPD_ACTIVE_WAKEUP, }, [MT8173_POWER_DOMAIN_MFG_ASYNC] = { + .name = "mfg_async", .sta_mask = PWR_STATUS_MFG_ASYNC, .ctl_offs = SPM_MFG_ASYNC_PWR_CON, .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = 0, }, [MT8173_POWER_DOMAIN_MFG_2D] = { + .name = "mfg_2d", .sta_mask = PWR_STATUS_MFG_2D, .ctl_offs = SPM_MFG_2D_PWR_CON, .sram_pdn_bits = GENMASK(11, 8), .sram_pdn_ack_bits = GENMASK(13, 12), }, [MT8173_POWER_DOMAIN_MFG] = { + .name = "mfg", .sta_mask = PWR_STATUS_MFG, .ctl_offs = SPM_MFG_PWR_CON, .sram_pdn_bits = GENMASK(13, 8),
drivers/soc/mediatek/mtk-pm-domains.c +5 -1
@@ -397,7 +397,11 @@ generic_pm_domain *scpsys_add_one_domain goto err_unprepare_subsys_clocks; } - pd->genpd.name = node->name; +if (!pd->data->name) + pd->genpd.name = node->name; +else + pd->genpd.name = pd->data->name; + pd->genpd.power_off = scpsys_power_off; pd->genpd.power_on = scpsys_power_on;
drivers/soc/mediatek/mtk-pm-domains.h +2 -0
@@ -74,6 +74,7 @@ struct scpsys_bus_prot_data {/** * struct scpsys_domain_data - scp domain data for power on/off flow +* @name: The name of the power domain. * @sta_mask: The mask for power on/off status bit. * @ctl_offs: The offset for main power control register. * @sram_pdn_bits: The mask for sram power control bits.
@@ -83,6 +84,7 @@ struct scpsys_bus_prot_data {* @bp_smi: bus protection for smi subsystem */ struct scpsys_domain_data { +const char *name;u32 sta_mask;int ctl_offs;u32 sram_pdn_bits;
Greg Kroah-Hartman
maintainerPATCH 318/329 soc: mediatek: pm-domains: Add a power domain names for mt8183
In reply to Greg Kroah-HartmanFrom: Enric Balletbo i Serra <[email protected]>
commit e57b8112258ed46dff23b49d6e400f54a8dbf1c3 upstream.
Add the power domains names for the mt8183 SoC. This removes the debugfs errors like the following:
debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!
--- drivers/soc/mediatek/mt8183-pm-domains.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
drivers/soc/mediatek/mt8183-pm-domains.h +15 -0
@@ -12,12 +12,14 @@static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = { [MT8183_POWER_DOMAIN_AUDIO ] = { + .name ="audio" , .sta_mask =PWR_STATUS_AUDIO , .ctl_offs =0x0314 , .sram_pdn_bits =GENMASK (11 ,8 ), .sram_pdn_ack_bits =GENMASK (15 ,12 ), }, [MT8183_POWER_DOMAIN_CONN ] = { + .name ="conn" , .sta_mask =PWR_STATUS_CONN , .ctl_offs =0x032c , .sram_pdn_bits =0 ,
@@ -28,30 +30,35 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_MFG_ASYNC] = { + .name = "mfg_async", .sta_mask = PWR_STATUS_MFG_ASYNC, .ctl_offs = 0x0334, .sram_pdn_bits = 0, .sram_pdn_ack_bits = 0, }, [MT8183_POWER_DOMAIN_MFG] = { + .name = "mfg", .sta_mask = PWR_STATUS_MFG, .ctl_offs = 0x0338, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8183_POWER_DOMAIN_MFG_CORE0] = { + .name = "mfg_core0", .sta_mask = BIT(7), .ctl_offs = 0x034c, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8183_POWER_DOMAIN_MFG_CORE1] = { + .name = "mfg_core1", .sta_mask = BIT(20), .ctl_offs = 0x0310, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8183_POWER_DOMAIN_MFG_2D] = { + .name = "mfg_2d", .sta_mask = PWR_STATUS_MFG_2D, .ctl_offs = 0x0348, .sram_pdn_bits = GENMASK(8, 8),
@@ -64,6 +71,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_DISP] = { + .name = "disp", .sta_mask = PWR_STATUS_DISP, .ctl_offs = 0x030c, .sram_pdn_bits = GENMASK(8, 8),
@@ -82,6 +90,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_CAM] = { + .name = "cam", .sta_mask = BIT(25), .ctl_offs = 0x0344, .sram_pdn_bits = GENMASK(9, 8),
@@ -104,6 +113,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_ISP] = { + .name = "isp", .sta_mask = PWR_STATUS_ISP, .ctl_offs = 0x0308, .sram_pdn_bits = GENMASK(9, 8),
@@ -126,6 +136,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_VDEC] = { + .name = "vdec", .sta_mask = BIT(31), .ctl_offs = 0x0300, .sram_pdn_bits = GENMASK(8, 8),
@@ -138,6 +149,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_VENC] = { + .name = "venc", .sta_mask = PWR_STATUS_VENC, .ctl_offs = 0x0304, .sram_pdn_bits = GENMASK(11, 8),
@@ -150,6 +162,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_VPU_TOP] = { + .name = "vpu_top", .sta_mask = BIT(26), .ctl_offs = 0x0324, .sram_pdn_bits = GENMASK(8, 8),
@@ -176,6 +189,7 @@ static const struct scpsys_domain_data s }, }, [MT8183_POWER_DOMAIN_VPU_CORE0] = { + .name = "vpu_core0", .sta_mask = BIT(27), .ctl_offs = 0x33c, .sram_pdn_bits = GENMASK(11, 8),
@@ -193,6 +207,7 @@ static const struct scpsys_domain_data s .caps = MTK_SCPD_SRAM_ISO, }, [MT8183_POWER_DOMAIN_VPU_CORE1] = { + .name = "vpu_core1", .sta_mask = BIT(28), .ctl_offs = 0x0340, .sram_pdn_bits = GENMASK(11, 8),
Greg Kroah-Hartman
maintainerPATCH 319/329 soc: mediatek: pm-domains: Add a power domain names for mt8192
In reply to Greg Kroah-HartmanFrom: Enric Balletbo i Serra <[email protected]>
commit 3edc01bc53c639b1c98f57e7f1c026aae6a25a62 upstream.
Add the power domains names for the mt8192 SoC.
--- drivers/soc/mediatek/mt8192-pm-domains.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/soc/mediatek/mt8192-pm-domains.h +21 -0
@@ -12,6 +12,7 @@static const struct scpsys_domain_data scpsys_domain_data_mt8192[] = { [MT8192_POWER_DOMAIN_AUDIO ] = { + .name ="audio" , .sta_mask =BIT (21 ), .ctl_offs =0x0354 , .sram_pdn_bits =GENMASK (8 ,8 ),
@@ -24,6 +25,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_CONN] = { + .name = "conn", .sta_mask = PWR_STATUS_CONN, .ctl_offs = 0x0304, .sram_pdn_bits = 0,
@@ -45,12 +47,14 @@ static const struct scpsys_domain_data s .caps = MTK_SCPD_KEEP_DEFAULT_OFF, }, [MT8192_POWER_DOMAIN_MFG0] = { + .name = "mfg0", .sta_mask = BIT(2), .ctl_offs = 0x0308, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_MFG1] = { + .name = "mfg1", .sta_mask = BIT(3), .ctl_offs = 0x030c, .sram_pdn_bits = GENMASK(8, 8),
@@ -75,36 +79,42 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_MFG2] = { + .name = "mfg2", .sta_mask = BIT(4), .ctl_offs = 0x0310, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_MFG3] = { + .name = "mfg3", .sta_mask = BIT(5), .ctl_offs = 0x0314, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_MFG4] = { + .name = "mfg4", .sta_mask = BIT(6), .ctl_offs = 0x0318, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_MFG5] = { + .name = "mfg5", .sta_mask = BIT(7), .ctl_offs = 0x031c, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_MFG6] = { + .name = "mfg6", .sta_mask = BIT(8), .ctl_offs = 0x0320, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_DISP] = { + .name = "disp", .sta_mask = BIT(20), .ctl_offs = 0x0350, .sram_pdn_bits = GENMASK(8, 8),
@@ -133,6 +143,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_IPE] = { + .name = "ipe", .sta_mask = BIT(14), .ctl_offs = 0x0338, .sram_pdn_bits = GENMASK(8, 8),
@@ -149,6 +160,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_ISP] = { + .name = "isp", .sta_mask = BIT(12), .ctl_offs = 0x0330, .sram_pdn_bits = GENMASK(8, 8),
@@ -165,6 +177,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_ISP2] = { + .name = "isp2", .sta_mask = BIT(13), .ctl_offs = 0x0334, .sram_pdn_bits = GENMASK(8, 8),
@@ -181,6 +194,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_MDP] = { + .name = "mdp", .sta_mask = BIT(19), .ctl_offs = 0x034c, .sram_pdn_bits = GENMASK(8, 8),
@@ -197,6 +211,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_VENC] = { + .name = "venc", .sta_mask = BIT(17), .ctl_offs = 0x0344, .sram_pdn_bits = GENMASK(8, 8),
@@ -213,6 +228,7 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_VDEC] = { + .name = "vdec", .sta_mask = BIT(15), .ctl_offs = 0x033c, .sram_pdn_bits = GENMASK(8, 8),
@@ -229,12 +245,14 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_VDEC2] = { + .name = "vdec2", .sta_mask = BIT(16), .ctl_offs = 0x0340, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_CAM] = { + .name = "cam", .sta_mask = BIT(23), .ctl_offs = 0x035c, .sram_pdn_bits = GENMASK(8, 8),
@@ -263,18 +281,21 @@ static const struct scpsys_domain_data s }, }, [MT8192_POWER_DOMAIN_CAM_RAWA] = { + .name = "cam_rawa", .sta_mask = BIT(24), .ctl_offs = 0x0360, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_CAM_RAWB] = { + .name = "cam_rawb", .sta_mask = BIT(25), .ctl_offs = 0x0364, .sram_pdn_bits = GENMASK(8, 8), .sram_pdn_ack_bits = GENMASK(12, 12), }, [MT8192_POWER_DOMAIN_CAM_RAWC] = { + .name = "cam_rawc", .sta_mask = BIT(26), .ctl_offs = 0x0368, .sram_pdn_bits = GENMASK(8, 8),
Greg Kroah-Hartman
maintainerPATCH 320/329 media: rkvdec: Remove of_match_ptr()
In reply to Greg Kroah-HartmanFrom: Fabio Estevam <[email protected]>
commit c2357dd9cbafc8ed37156e32c24884cfa8380b2f upstream.
When building with CONFIG_OF not set, the following clang build warning is seen:
Quoted 1 line
Quoted 1 line
drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 'of_rkvdec_match' [-Wunused-const-variable]
Fix the warning by removing the unnecessary of_match_ptr().
--- drivers/staging/media/rkvdec/rkvdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/media/rkvdec/rkvdec.c +1 -1
@@ -1072,7 +1072,7 @@ static struct platform_driver rkvdec_dri .remove = rkvdec_remove, .driver = { .name = "rkvdec", - .of_match_table = of_match_ptr(of_rkvdec_match), + .of_match_table = of_rkvdec_match, .pm = &rkvdec_pm_ops, }, };
Greg Kroah-Hartman
maintainerPATCH 321/329 i2c: mediatek: Fix send master code at more than 1MHz
In reply to Greg Kroah-HartmanFrom: Qii Wang <[email protected]>
commit 63ce8e3df8f6deca2da52eaf064751ad4018b46e upstream.
There are some omissions in the previous patch about replacing I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and need to fix it.
--- drivers/i2c/busses/i2c-mt65xx.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/i2c/busses/i2c-mt65xx.c +5 -4
@@ -564,7 +564,7 @@ static const struct i2c_spec_values *mtkstatic int mtk_i2c_max_step_cnt (unsigned int target_speed) { -if (target_speed >I2C_MAX_FAST_MODE_FREQ ) +if (target_speed >I2C_MAX_FAST_MODE_PLUS_FREQ )return MAX_HS_STEP_CNT_DIV ;else return MAX_STEP_CNT_DIV ;
@@ -635,7 +635,7 @@ static int mtk_i2c_check_ac_timing(strucif (sda_min > sda_max)return -3 ; -if (check_speed >I2C_MAX_FAST_MODE_FREQ ) { +if (check_speed >I2C_MAX_FAST_MODE_PLUS_FREQ ) {if (i2c->dev_comp->ltiming_adjust) { i2c->ac_timing.hs =I2C_TIME_DEFAULT_VALUE | (sample_cnt <<12 ) | (high_cnt <<8 );
@@ -850,7 +850,7 @@ static int mtk_i2c_do_transfer(struct mt control_reg =mtk_i2c_readw (i2c,OFFSET_CONTROL ) & ~(I2C_CONTROL_DIR_CHANGE |I2C_CONTROL_RS ); -if ((i2c->speed_hz >I2C_MAX_FAST_MODE_FREQ ) || (left_num >=1 )) +if ((i2c->speed_hz >I2C_MAX_FAST_MODE_PLUS_FREQ ) || (left_num >=1 )) control_reg |=I2C_CONTROL_RS ;if (i2c->op ==I2C_MASTER_WRRD )
@@ -1067,7 +1067,8 @@ static int mtk_i2c_transfer(struct i2c_a } } -if (i2c->auto_restart && num >=2 && i2c->speed_hz >I2C_MAX_FAST_MODE_FREQ ) +if (i2c->auto_restart && num >=2 && + i2c->speed_hz >I2C_MAX_FAST_MODE_PLUS_FREQ )/* ignore the first restart irq after the master code, * otherwise the first transfer will be discarded. */
Greg Kroah-Hartman
maintainerPATCH 322/329 dt-bindings: media: renesas,vin: Make resets optional on R-Car Gen1
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit 7935bb56e21b2add81149f4def8e59b4133fe57c upstream.
The "resets" property is not present on R-Car Gen1 SoCs. Supporting it would require migrating from renesas,cpg-clocks to renesas,cpg-mssr.
--- Documentation/devicetree/bindings/media/renesas,vin.yaml | 44 +++++++++------ 1 file changed, 28 insertions(+), 16 deletions(-)
Documentation/devicetree/bindings/media/renesas,vin.yaml +28 -16
@@ -278,23 +278,35 @@ required: - interrupts - clocks - power-domains - - resets -if: - properties: - compatible: - contains: - enum: - - renesas,vin-r8a7778 - - renesas,vin-r8a7779 - - renesas,rcar-gen2-vin -then: - required: - - port -else: - required: - - renesas,id - - ports +allOf: + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,vin-r8a7778 + - renesas,vin-r8a7779 + then: + required: + - resets + + - if: + properties: + compatible: + contains: + enum: + - renesas,vin-r8a7778 + - renesas,vin-r8a7779 + - renesas,rcar-gen2-vin + then: + required: + - port + else: + required: + - renesas,id + - ports additionalProperties: false
Greg Kroah-Hartman
maintainerPATCH 323/329 dt-bindings: thermal: rcar-gen3-thermal: Support five TSC nodes on r8a779a0
In reply to Greg Kroah-HartmanFrom: Niklas Söderlund <[email protected]>
commit 9468e7b031876935230182628f8d5f216c071784 upstream.
When adding support for V3U (r8a779a0) it was incorrectly recorded it supports four nodes, while in fact it supports five. The fifth node is named TSC0 and breaks the existing naming schema starting at 1. Work around this by separately defining the reg property for V3U and others.
Restore the maximum number of nodes to three for other compatibles as it was before erroneously increasing it for V3U.
--- Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml | 43 ++++++++-- 1 file changed, 35 insertions(+), 8 deletions(-)
Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml +35 -8
@@ -28,14 +28,7 @@ properties: - renesas,r8a77980-thermal # R-Car V3H - renesas,r8a779a0-thermal # R-Car V3U - reg: - minItems: 2 - maxItems: 4 - items: - - description: TSC1 registers - - description: TSC2 registers - - description: TSC3 registers - - description: TSC4 registers + reg: true interrupts: items:
@@ -71,8 +64,25 @@ if: enum: - renesas,r8a779a0-thermal then: + properties: + reg: + minItems: 2 + maxItems: 3 + items: + - description: TSC1 registers + - description: TSC2 registers + - description: TSC3 registers required: - interrupts +else: + properties: + reg: + items: + - description: TSC0 registers + - description: TSC1 registers + - description: TSC2 registers + - description: TSC3 registers + - description: TSC4 registers additionalProperties: false
@@ -111,3 +121,20 @@ examples: }; }; }; + - | + #include <dt-bindings/clock/r8a779a0-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a779a0-sysc.h> + + tsc_r8a779a0: thermal@e6190000 { + compatible = "renesas,r8a779a0-thermal"; + reg = <0xe6190000 0x200>, + <0xe6198000 0x200>, + <0xe61a0000 0x200>, + <0xe61a8000 0x200>, + <0xe61b0000 0x200>; + clocks = <&cpg CPG_MOD 919>; + power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; + resets = <&cpg 919>; + #thermal-sensor-cells = <1>; + };
Greg Kroah-Hartman
maintainerPATCH 324/329 dt-bindings: serial: 8250: Remove duplicated compatible strings
In reply to Greg Kroah-HartmanFrom: Zhen Lei <[email protected]>
commit a7277a73984114b38dcb62c8548850800ffe864e upstream.
The compatible strings "mediatek,*" appears two times, remove one of them.
--- Documentation/devicetree/bindings/serial/8250.yaml | 5 ----- 1 file changed, 5 deletions(-)
Documentation/devicetree/bindings/serial/8250.yaml +0 -5
@@ -94,11 +94,6 @@ properties: - mediatek,mt7623-btif - const: mediatek,mtk-btif - items: - - enum: - - mediatek,mt7622-btif - - mediatek,mt7623-btif - - const: mediatek,mtk-btif - - items: - const: mrvl,mmp-uart - const: intel,xscale-uart - items:
Greg Kroah-Hartman
maintainerPATCH 325/329 dt-bindings: PCI: rcar-pci-host: Document missing R-Car H1 support
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit 62b3b3660aff66433d71f142ab6ed2baaea25025 upstream.
scripts/checkpatch.pl -f drivers/pci/controller/pcie-rcar-host.c:
WARNING: DT compatible string "renesas,pcie-r8a7779" appears un-documented -- check ./Documentation/devicetree/bindings/
#853: FILE: drivers/pci/controller/pcie-rcar-host.c:853:
+ { .compatible = "renesas,pcie-r8a7779",Re-add the compatible value for R-Car H1, which was lost during the json-schema conversion. Make the "resets" property optional on R-Car H1, as it is not present yet on R-Car Gen1 SoCs.
--- Documentation/devicetree/bindings/pci/rcar-pci-host.yaml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/pci/rcar-pci-host.yaml +11 -1
@@ -17,6 +17,7 @@ allOf: properties: compatible: oneOf: + - const: renesas,pcie-r8a7779 # R-Car H1 - items: - enum: - renesas,pcie-r8a7742 # RZ/G1H
@@ -74,7 +75,16 @@ required: - clocks - clock-names - power-domains - - resets + +if: + not: + properties: + compatible: + contains: + const: renesas,pcie-r8a7779 +then: + required: + - resets unevaluatedProperties: false
Greg Kroah-Hartman
maintainerPATCH 326/329 debugfs: Make debugfs_allow RO after init
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
commit 312723a0b34d6d110aa4427a982536bb36ab8471 upstream.
Since debugfs_allow is only set at boot time during __init, make it read-only after being set.
--- fs/debugfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/debugfs/inode.c +1 -1
@@ -35,7 +35,7 @@static struct vfsmount *debugfs_mount;static int debugfs_mount_count;static bool debugfs_registered; -static unsigned int debugfs_allow =DEFAULT_DEBUGFS_ALLOW_BITS ; +static unsigned int debugfs_allow__ro_after_init =DEFAULT_DEBUGFS_ALLOW_BITS ;/* * Don't allow access attributes to be changed whilst the kernel is locked down
Greg Kroah-Hartman
maintainerPATCH 327/329 ext4: fix debug format string warning
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit fcdf3c34b7abdcbb49690c94c7fa6ce224dc9749 upstream.
Using no_printk() for jbd_debug() revealed two warnings:
fs/jbd2/recovery.c: In function 'fc_do_one_pass':fs/jbd2/recovery.c:256:30: error: format '%d' expects a matching 'int' argument [-Werror=format=]
256 | jbd_debug(3, "Processing fast commit blk with seq %d");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/ext4/fast_commit.c: In function 'ext4_fc_replay_add_range':fs/ext4/fast_commit.c:1732:30: error: format '%d' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Werror=format=]
1732 | jbd_debug(1, "Converting from %d to %d %lld",
The first one was added incorrectly, and was also missing a few newlines in debug output, and the second one happened when the type of an argument changed.
--- fs/ext4/fast_commit.c | 2 +- fs/jbd2/recovery.c | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
fs/ext4/fast_commit.c +1 -1
@@ -1743,7 +1743,7 @@ static int ext4_fc_replay_add_range(stru }/* Range is mapped and needs a state change */ -jbd_debug (1 ,"Converting from %d to %d %lld" , +jbd_debug (1 ,"Converting from %ld to %d %lld" , map.m_flags &EXT4_MAP_UNWRITTEN ,ext4_ext_is_unwritten (ex), map.m_pblk); ret = ext4_ext_replay_update_ex(inode, cur, map.m_len,
fs/jbd2/recovery.c +2 -3
@@ -245,15 +245,14 @@ static int fc_do_one_pass(journal_t *joureturn 0 ;while (next_fc_block <= journal->j_fc_last) { -jbd_debug (3 ,"Fast commit replay: next block %ld" , +jbd_debug (3 ,"Fast commit replay: next block %ld\n" , next_fc_block); err =jread (&bh, journal, next_fc_block);if (err) { -jbd_debug (3 ,"Fast commit replay: read error" ); +jbd_debug (3 ,"Fast commit replay: read error\n" );break ; } -jbd_debug (3 ,"Processing fast commit blk with seq %d" ); err = journal->j_fc_replay_callback (journal, bh, pass, next_fc_block - journal->j_fc_first, expected_commit_id);
Greg Kroah-Hartman
maintainerPATCH 328/329 nvme: do not try to reconfigure APST when the controller is not live
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit 53fe2a30bc168db9700e00206d991ff934973cf1 upstream.
Do not call nvme_configure_apst when the controller is not live, given that nvme_configure_apst will fail due the lack of an admin queue when the controller is being torn down and nvme_set_latency_tolerance is called from dev_pm_qos_hide_latency_tolerance.
--- drivers/nvme/host/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/core.c +2 -1
@@ -2676,7 +2676,8 @@ static void nvme_set_latency_tolerance(sif (ctrl->ps_max_latency_us != latency) { ctrl->ps_max_latency_us = latency; -nvme_configure_apst (ctrl); +if (ctrl->state ==NVME_CTRL_LIVE ) +nvme_configure_apst (ctrl); } }
Greg Kroah-Hartman
maintainerPATCH 329/329 ASoC: rsnd: check all BUSIF status when error
In reply to Greg Kroah-HartmanFrom: Kuninori Morimoto <[email protected]>
commit a4856e15e58b54977f1c0c0299309ad4d1f13365 upstream.
commit 66c705d07d784 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") adds __rsnd_ssi_interrupt() checks for BUSIF status, but is using "break" at for loop.
This means it is not checking all status. Let's check all BUSIF status.
--- sound/soc/sh/rcar/ssi.c | 2 -- 1 file changed, 2 deletions(-)
sound/soc/sh/rcar/ssi.c +0 -2
@@ -797,7 +797,6 @@ static void __rsnd_ssi_interrupt(structSSI_SYS_STATUS (i *2 ), 0xf << (id * 4)); stop = true; -break ; } }break ;
@@ -815,7 +814,6 @@ static void __rsnd_ssi_interrupt(structSSI_SYS_STATUS ((i *2 ) +1 ), 0xf << 4); stop = true; -break ; } }break ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
Since we are still missing some key dependencies from 5.12 to boot properly on ARCH_BRCMSTB I only build tested this branch to make sure that ahci_brcm.c and pcie-brcmstb.c built fine, thanks!
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.11:
12 builds: 12 pass, 0 fail
28 boots: 28 pass, 0 fail
70 tests: 70 pass, 0 failLinux version: 5.11.22-rc1-g6d09fa399bd5
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
5.11.22-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.11.22-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.11.y
* git commit: 6d09fa399bd51fced0a3ad760d2b28f3cfca1678
* git describe: v5.11.21-330-g6d09fa399bd5
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.11.y/build/v5.11.21-330-g6d09fa399bd5
## No regressions (compared to v5.11.21)
## Fixes (compared to v5.11.21)
* mips, build
- clang-10-allnoconfig
- clang-10-defconfig
- clang-10-tinyconfig
- clang-11-allnoconfig
- clang-11-defconfig
- clang-11-tinyconfig
- clang-12-allnoconfig
- clang-12-defconfig
- clang-12-tinyconfig
## Test result summary
total: 77570, pass: 64809, fail: 945, skip: 11208, xfail: 608,
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 193 total, 193 passed, 0 failed
* arm64: 27 total, 27 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 26 total, 26 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 0 passed, 1 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.11.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.22 release. There are 329 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 19 May 2021 14:02:16 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 461 pass: 461 fail: 0
Guenter