Re: [PATCH] x86/irq: Lower unhandled irq error severity
Hello, On Fri, Nov 27, 2020, at 02:12, Thomas Gleixner wrote: > On Thu, Nov 26 2020 at 09:47, Laurențiu Nicola wrote: > > These messages are described as warnings in the MSI code. > > Where and what has MSI to do with these messages? There's a comment referring to it as a warning, but an error seemed a more appropriate severity: * If the vector is unused, then it is marked so it won't * trigger the 'No irq handler for vector' warning in * common_interrupt(). > > Spotted because they break quiet boot on a Ryzen 5000 CPU. > > They don't break the boot. > > The machine boots fine, but having interrupts raised on a vector which > is unused is really bad. That's right, sorry. It still boots, but it's no longer "quiet", that's what I meant. > Can you please provide the actual message from dmesg? Sure: [0.316902] __common_interrupt: 1.55 No irq handler for vector [0.316902] __common_interrupt: 2.55 No irq handler for vector [0.316902] __common_interrupt: 3.55 No irq handler for vector [0.316902] __common_interrupt: 4.55 No irq handler for vector [0.316902] __common_interrupt: 5.55 No irq handler for vector [0.316902] __common_interrupt: 6.55 No irq handler for vector [0.316902] __common_interrupt: 7.55 No irq handler for vector [0.316902] __common_interrupt: 8.55 No irq handler for vector [0.316902] __common_interrupt: 9.55 No irq handler for vector [0.316902] __common_interrupt: 10.55 No irq handler for vector These only show up during boot (and not e.g. when a disabling and enabling again a CPU). Laurențiu
Re: [PATCH] mm: fix some spelling mistakes in comments
On Fri, Nov 27, 2020 at 09:17:47AM +0800, Haitao Shi wrote: > Fix some spelling mistakes in comments: > udpate ==> update > succesful ==> successful > exmaple ==> example > unneccessary ==> unnecessary > stoping ==> stopping > uknown ==> unknown > > Signed-off-by: Haitao Shi Reviewed-by: Mike Rapoport > --- > mm/filemap.c | 2 +- > mm/huge_memory.c | 2 +- > mm/khugepaged.c | 2 +- > mm/memblock.c| 2 +- > mm/migrate.c | 2 +- > mm/page_ext.c| 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 3ebbe64..8826c48 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -1359,7 +1359,7 @@ static int __wait_on_page_locked_async(struct page > *page, > else > ret = PageLocked(page); > /* > - * If we were succesful now, we know we're still on the > + * If we were successful now, we know we're still on the >* waitqueue as we're still under the lock. This means it's >* safe to remove and return success, we know the callback >* isn't going to trigger. > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index ec2bb93..0fea0c2 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2356,7 +2356,7 @@ static void __split_huge_page_tail(struct page *head, > int tail, >* Clone page flags before unfreezing refcount. >* >* After successful get_page_unless_zero() might follow flags change, > - * for exmaple lock_page() which set PG_waiters. > + * for example lock_page() which set PG_waiters. >*/ > page_tail->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; > page_tail->flags |= (head->flags & > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 4e3dff1..d6f7ede 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1273,7 +1273,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm, >* PTEs are armed with uffd write protection. >* Here we can also mark the new huge pmd as >* write protected if any of the small ones is > - * marked but that could bring uknown > + * marked but that could bring unknown >* userfault messages that falls outside of >* the registered range. So, just be simple. >*/ > diff --git a/mm/memblock.c b/mm/memblock.c > index b68ee86..086662a 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -871,7 +871,7 @@ int __init_memblock memblock_physmem_add(phys_addr_t > base, phys_addr_t size) > * @base: base address of the region > * @size: size of the region > * @set: set or clear the flag > - * @flag: the flag to udpate > + * @flag: the flag to update > * > * This function isolates region [@base, @base + @size), and sets/clears flag > * > diff --git a/mm/migrate.c b/mm/migrate.c > index 5795cb8..8a3580c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -2548,7 +2548,7 @@ static bool migrate_vma_check_page(struct page *page) >* will bump the page reference count. Sadly there is no way to >* differentiate a regular pin from migration wait. Hence to >* avoid 2 racing thread trying to migrate back to CPU to enter > - * infinite loop (one stoping migration because the other is > + * infinite loop (one stopping migration because the other is >* waiting on pte migration entry). We always return true here. >* >* FIXME proper solution is to rework migration_entry_wait() so > diff --git a/mm/page_ext.c b/mm/page_ext.c > index a3616f7..cf931eb 100644 > --- a/mm/page_ext.c > +++ b/mm/page_ext.c > @@ -34,7 +34,7 @@ > * > * The need callback is used to decide whether extended memory allocation is > * needed or not. Sometimes users want to deactivate some features in this > - * boot and extra memory would be unneccessary. In this case, to avoid > + * boot and extra memory would be unnecessary. In this case, to avoid > * allocating huge chunk of memory, each clients represent their need of > * extra memory through the need callback. If one of the need callbacks > * returns true, it means that someone needs extra memory so that > -- > 2.10.1 > -- Sincerely yours, Mike.
Re: [PATCH 01/16] mfd: bcm590xx: drop of_match_ptr from of_device_id table
On Fri, 20 Nov 2020, Krzysztof Kozlowski wrote: > The driver can match only via the DT table so the table should be always > used and the of_match_ptr does not have any sense (this also allows ACPI > matching via PRP0001, even though it is not relevant here). This fixes > compile warning (!CONFIG_OF on x86_64): > > drivers/mfd/bcm590xx.c:95:34: warning: ‘bcm590xx_of_match’ defined but not > used [-Wunused-const-variable=] > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/mfd/bcm590xx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Couple of small points: - Patch-sets, particularly large ones should have a cover letter. - Subject lines follow English grammar conventions and should start with an uppercase character. I fixed all of these patches with respect to the above and applied them all however. All patches applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH bpf-next 1/2] bpf: Expose bpf_get_socket_cookie to tracing programs
On 11/26/20 9:02 AM, Florent Revest wrote:
This creates a new helper proto because the existing
bpf_get_socket_cookie_sock_proto has a ARG_PTR_TO_CTX argument and only
works for BPF programs where the context is a sock.
This helper could also be useful to other BPF program types such as LSM.
Signed-off-by: Florent Revest
---
kernel/trace/bpf_trace.c | 4
net/core/filter.c| 7 +++
2 files changed, 11 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d255bc9b2bfa..14ad96579813 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1725,6 +1725,8 @@ raw_tp_prog_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
}
}
+extern const struct bpf_func_proto bpf_get_socket_cookie_sock_tracing_proto;
+
const struct bpf_func_proto *
tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
@@ -1748,6 +1750,8 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return _sk_storage_get_tracing_proto;
case BPF_FUNC_sk_storage_delete:
return _sk_storage_delete_tracing_proto;
+ case BPF_FUNC_get_socket_cookie:
+ return _get_socket_cookie_sock_tracing_proto;
#endif
case BPF_FUNC_seq_printf:
return prog->expected_attach_type == BPF_TRACE_ITER ?
diff --git a/net/core/filter.c b/net/core/filter.c
index 2ca5eecebacf..177c4e5e529d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4631,6 +4631,13 @@ static const struct bpf_func_proto
bpf_get_socket_cookie_sock_proto = {
.arg1_type = ARG_PTR_TO_CTX,
};
+const struct bpf_func_proto bpf_get_socket_cookie_sock_tracing_proto = {
+ .func = bpf_get_socket_cookie_sock,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_BTF_ID_SOCK_COMMON,
+};
This seems correct to me. Could you add another helper description in
uapi bpf.h? Currently we already have:
u64 bpf_get_socket_cookie(struct sk_buff *skb)
u64 bpf_get_socket_cookie(struct bpf_sock_addr *ctx)
u64 bpf_get_socket_cookie(struct bpf_sock_ops *ctx)
The btf-id based helper will be something like below
u64 bpf_get_socket_cookie(void *sk)
+
BPF_CALL_1(bpf_get_socket_cookie_sock_ops, struct bpf_sock_ops_kern *, ctx)
{
return __sock_gen_cookie(ctx->sk);
Re: [PATCH 1/3] mm,thp,shmem: limit shmem THP alloc gfp_mask
On Tue 24-11-20 14:49:23, Rik van Riel wrote:
> The allocation flags of anonymous transparent huge pages can be controlled
> through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
> help the system from getting bogged down in the page reclaim and compaction
> code when many THPs are getting allocated simultaneously.
>
> However, the gfp_mask for shmem THP allocations were not limited by those
> configuration settings, and some workloads ended up with all CPUs stuck
> on the LRU lock in the page reclaim code, trying to allocate dozens of
> THPs simultaneously.
>
> This patch applies the same configurated limitation of THPs to shmem
> hugepage allocations, to prevent that from happening.
>
> Controlling the gfp_mask of THP allocations through the knobs in
> sysfs allows users to determine the balance between how aggressively
> the system tries to allocate THPs at fault time, and how much the
> application may end up stalling attempting those allocations.
>
> This way a THP defrag setting of "never" or "defer+madvise" will result
> in quick allocation failures without direct reclaim when no 2MB free
> pages are available.
>
> With this patch applied, THP allocations for tmpfs will be a little
> more aggressive than today for files mmapped with MADV_HUGEPAGE,
> and a little less aggressive for files that are not mmapped or
> mapped without that flag.
As already said I am not against this unification. On the other I really
hope that we will not hear about somebody really requesting a per mount
control over this behavior because some might be benefiting from THPs
more than others and the initial cost would pay off. This is not
something we do care about now so this patch wouldn't regress in that
aspect.
> Signed-off-by: Rik van Riel
Acked-by: Michal Hocko
Btw. Documentation/admin-guide/mm/transhuge.rst needs some update as
well. What about the following?
diff --git a/Documentation/admin-guide/mm/transhuge.rst
b/Documentation/admin-guide/mm/transhuge.rst
index b2acd0d395ca..41fe84c5b808 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -104,7 +104,7 @@ regions (to avoid the risk of consuming more memory
resources) or enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled
It's also possible to limit defrag efforts in the VM to generate
-anonymous hugepages in case they're not immediately free to madvise
+anonymous and shmem hugepages in case they're not immediately free to madvise
regions or to never try to defrag memory and simply fallback to regular
pages unless hugepages are immediately available. Clearly if we spend CPU
time to defrag memory, we would expect to gain even more by the fact we
> ---
> include/linux/gfp.h | 2 ++
> mm/huge_memory.c| 6 +++---
> mm/shmem.c | 8 +---
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index c603237e006c..c7615c9ba03c 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -614,6 +614,8 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask);
> extern void pm_restrict_gfp_mask(void);
> extern void pm_restore_gfp_mask(void);
>
> +extern gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma);
> +
> #ifdef CONFIG_PM_SLEEP
> extern bool pm_suspended_storage(void);
> #else
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9474dbc150ed..c5d03b2f2f2f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -649,9 +649,9 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf,
> * available
> * never: never stall for any thp allocation
> */
> -static inline gfp_t alloc_hugepage_direct_gfpmask(struct vm_area_struct *vma)
> +gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma)
> {
> - const bool vma_madvised = !!(vma->vm_flags & VM_HUGEPAGE);
> + const bool vma_madvised = vma && (vma->vm_flags & VM_HUGEPAGE);
>
> /* Always do synchronous compaction */
> if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG,
> _hugepage_flags))
> @@ -744,7 +744,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault
> *vmf)
> pte_free(vma->vm_mm, pgtable);
> return ret;
> }
> - gfp = alloc_hugepage_direct_gfpmask(vma);
> + gfp = vma_thp_gfp_mask(vma);
> page = alloc_hugepage_vma(gfp, vma, haddr, HPAGE_PMD_ORDER);
> if (unlikely(!page)) {
> count_vm_event(THP_FAULT_FALLBACK);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 537c137698f8..6c3cb192a88d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1545,8 +1545,8 @@ static struct page *shmem_alloc_hugepage(gfp_t gfp,
> return NULL;
>
> shmem_pseudo_vma_init(, info, hindex);
> - page = alloc_pages_vma(gfp | __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN,
> - HPAGE_PMD_ORDER, , 0, numa_node_id(), true);
> + page = alloc_pages_vma(gfp, HPAGE_PMD_ORDER, , 0,
Re: [PATCH 0/6] Add SBI v0.2 support for KVM
On Mon, Aug 3, 2020 at 11:29 PM Atish Patra wrote: > > The Supervisor Binary Interface(SBI) specification[1] now defines a > base extension that provides extendability to add future extensions > while maintaining backward compatibility with previous versions. > The new version is defined as 0.2 and older version is marked as 0.1. > > This series adds following features to RISC-V Linux KVM. > 1. Adds support for SBI v0.2 in KVM > 2. SBI Hart state management extension (HSM) in KVM > 3. Ordered booting of guest vcpus in guest Linux > > This series depends on the base kvm support series[2]. > > Guest kernel needs to also support SBI v0.2 and HSM extension in Kernel > to boot multiple vcpus. Linux kernel supports both starting v5.7. > In absense of that, guest can only boot 1vcpu. > > [1] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc > [2] http://lists.infradead.org/pipermail/linux-riscv/2020-July/001028.html > > Atish Patra (6): > RISC-V: Add a non-void return for sbi v02 functions > RISC-V: Mark the existing SBI v0.1 implementation as legacy > RISC-V: Reorganize SBI code by moving legacy SBI to its own file > RISC-V: Add SBI v0.2 base extension > RISC-V: Add v0.1 replacement SBI extensions defined in v02 > RISC-V: Add SBI HSM extension in KVM > > arch/riscv/include/asm/kvm_vcpu_sbi.h | 32 + > arch/riscv/include/asm/sbi.h | 17 ++- > arch/riscv/kernel/sbi.c | 32 ++--- > arch/riscv/kvm/Makefile | 4 +- > arch/riscv/kvm/vcpu.c | 19 +++ > arch/riscv/kvm/vcpu_sbi.c | 194 -- > arch/riscv/kvm/vcpu_sbi_base.c| 73 ++ > arch/riscv/kvm/vcpu_sbi_hsm.c | 109 +++ > arch/riscv/kvm/vcpu_sbi_legacy.c | 129 + > arch/riscv/kvm/vcpu_sbi_replace.c | 136 ++ > 10 files changed, 619 insertions(+), 126 deletions(-) > create mode 100644 arch/riscv/include/asm/kvm_vcpu_sbi.h > create mode 100644 arch/riscv/kvm/vcpu_sbi_base.c > create mode 100644 arch/riscv/kvm/vcpu_sbi_hsm.c > create mode 100644 arch/riscv/kvm/vcpu_sbi_legacy.c > create mode 100644 arch/riscv/kvm/vcpu_sbi_replace.c > > -- > 2.24.0 > Please implement the SBI SRST extension in your series. Also, the PATCH1 can be merged separately so I would suggest you to send this patch separately. Regards, Anup
Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on reads
On Thu, Nov 26, 2020 at 05:23:59PM -0500, Peter Xu wrote:
> Faulting around for reads are in most cases helpful for the performance so
> that
> continuous memory accesses may avoid another trip of page fault. However it
> may not always work as expected.
>
> For example, userfaultfd registered regions may not be the best candidate for
> pre-faults around the reads.
>
> For missing mode uffds, fault around does not help because if the page cache
> existed, then the page should be there already. If the page cache is not
> there, nothing else we can do, either. If the fault-around code is destined
> to
> be helpless for userfault-missing vmas, then ideally we can skip it.
>
> For wr-protected mode uffds, errornously fault in those pages around could
> lead
> to threads accessing the pages without uffd server's awareness. For example,
> when punching holes on uffd-wp registered shmem regions, we'll first try to
> unmap all the pages before evicting the page cache but without locking the
> page (please refer to shmem_fallocate(), where unmap_mapping_range() is called
> before shmem_truncate_range()). When fault-around happens near a hole being
> punched, we might errornously fault in the "holes" right before it will be
> punched. Then there's a small window before the page cache was finally
> dropped, and after the page will be writable again (NOTE: the uffd-wp protect
> information is totally lost due to the pre-unmap in shmem_fallocate(), so the
> page can be writable within the small window). That's severe data loss.
>
> Let's grant the userspace full control of the uffd-registered ranges, rather
> than trying to do the tricks.
>
> Cc: Hugh Dickins
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Signed-off-by: Peter Xu
One nit below, except that
Reviewed-by: Mike Rapoport
> ---
>
> Note that since no file-backed uffd-wp support is there yet upstream, so the
> uffd-wp check is actually not really functioning. However since we have all
> the necessary uffd-wp concepts already upstream, maybe it's better to do it
> once and for all.
>
> This patch comes from debugging a data loss issue when working on the uffd-wp
> support on shmem/hugetlbfs. I posted this out for early review and comments,
> but also because it should already start to benefit missing mode userfaultfd
> to
> avoid trying to fault around on reads.
> ---
> include/linux/userfaultfd_k.h | 5 +
> mm/memory.c | 17 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> index a8e5f3ea9bb2..451d99bb3a1a 100644
> --- a/include/linux/userfaultfd_k.h
> +++ b/include/linux/userfaultfd_k.h
> @@ -62,6 +62,11 @@ static inline bool userfaultfd_wp(struct vm_area_struct
> *vma)
> return vma->vm_flags & VM_UFFD_WP;
> }
>
> +static inline bool vma_registered_userfaultfd(struct vm_area_struct *vma)
> +{
> + return userfaultfd_missing(vma) || userfaultfd_wp(vma);
> +}
We have userfaultfd_armed() that does exectly this, don't we?
> +
> static inline bool userfaultfd_pte_wp(struct vm_area_struct *vma,
> pte_t pte)
> {
> diff --git a/mm/memory.c b/mm/memory.c
> index eeae590e526a..ca58ada94c96 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3933,6 +3933,23 @@ static vm_fault_t do_fault_around(struct vm_fault *vmf)
> int off;
> vm_fault_t ret = 0;
>
> + /*
> + * Be extremely careful with uffd-armed regions.
> + *
> + * For missing mode uffds, fault around does not help because if the
> + * page cache existed, then the page should be there already. If the
> + * page cache is not there, nothing else we can do either.
> + *
> + * For wr-protected mode uffds, errornously fault in those pages around
> + * could lead to threads accessing the pages without uffd server's
> + * awareness, finally it could cause ghostly data corruption.
> + *
> + * The idea is that, every single page of uffd regions should be
> + * governed by the userspace on which page to fault in.
> + */
> + if (unlikely(vma_registered_userfaultfd(vmf->vma)))
> + return 0;
> +
> nr_pages = READ_ONCE(fault_around_bytes) >> PAGE_SHIFT;
> mask = ~(nr_pages * PAGE_SIZE - 1) & PAGE_MASK;
>
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
Re: [PATCH 01/16] mfd: bcm590xx: drop of_match_ptr from of_device_id table
On Fri, 27 Nov 2020 at 09:06, Lee Jones wrote: > > On Fri, 20 Nov 2020, Krzysztof Kozlowski wrote: > > > The driver can match only via the DT table so the table should be always > > used and the of_match_ptr does not have any sense (this also allows ACPI > > matching via PRP0001, even though it is not relevant here). This fixes > > compile warning (!CONFIG_OF on x86_64): > > > > drivers/mfd/bcm590xx.c:95:34: warning: ‘bcm590xx_of_match’ defined but > > not used [-Wunused-const-variable=] > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > drivers/mfd/bcm590xx.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Couple of small points: > > - Patch-sets, particularly large ones should have a cover letter. > - Subject lines follow English grammar conventions and should start > with an uppercase character. Thanks for fixing this. I am not a native English speaker and I make mistakes. Either it is a grammar or convention mistake, I would appreciate it if you point them out, so I could learn from them. About the "start with an uppercase character", I actually on purpose changed my approach some time ago after seeing more senior kernel developers using this method (see commits from Linus Torvalds, Andrew Morton). After the subsystem prefix "mfd: " they start with lowercase. If you still insist that commit titles in MFD subsystem should use capital letter after the prefix, I will try to remember and follow this approach when sending patches to you. Best regards, Krzysztof
Re: [PATCH 1/2] mm/debug_vm_pgtable/basic: Add validation for dirtiness after write protect
Le 27/11/2020 à 06:06, Anshuman Khandual a écrit : This adds validation tests for dirtiness after write protect conversion for each page table level. This is important for platforms such as arm64 that removes the hardware dirty bit while making it an write protected one. This also fixes pxx_wrprotect() related typos in the documentation file. diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c index c05d9dcf7891..a5be11210597 100644 --- a/mm/debug_vm_pgtable.c +++ b/mm/debug_vm_pgtable.c @@ -70,6 +70,7 @@ static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(pte_young(pte_mkold(pte_mkyoung(pte; WARN_ON(pte_dirty(pte_mkclean(pte_mkdirty(pte; WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte; + WARN_ON(pte_dirty(pte_wrprotect(pte))); Wondering what you are testing here exactly. Do you expect that if PTE has the dirty bit, it gets cleared by pte_wrprotect() ? Powerpc doesn't do that, it only clears the RW bit but the dirty bit remains if it is set, until you call pte_mkclean() explicitely. } static void __init pte_advanced_tests(struct mm_struct *mm, @@ -144,6 +145,7 @@ static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(pmd_young(pmd_mkold(pmd_mkyoung(pmd; WARN_ON(pmd_dirty(pmd_mkclean(pmd_mkdirty(pmd; WARN_ON(pmd_write(pmd_wrprotect(pmd_mkwrite(pmd; + WARN_ON(pmd_dirty(pmd_wrprotect(pmd))); /* * A huge page does not point to next level page table * entry. Hence this must qualify as pmd_bad(). @@ -262,6 +264,7 @@ static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(!pud_write(pud_mkwrite(pud_wrprotect(pud; WARN_ON(pud_write(pud_wrprotect(pud_mkwrite(pud; WARN_ON(pud_young(pud_mkold(pud_mkyoung(pud; + WARN_ON(pud_dirty(pud_wrprotect(pud))); if (mm_pmd_folded(mm)) return; Christophe
Re: [PATCH bpf v2 2/2] xsk: change the tx writeable condition
On Wed, Nov 25, 2020 at 7:49 AM Xuan Zhuo wrote:
>
> Modify the tx writeable condition from the queue is not full to the
> number of present tx queues is less than the half of the total number
> of queues. Because the tx queue not full is a very short time, this will
> cause a large number of EPOLLOUT events, and cause a large number of
> process wake up.
>
> Signed-off-by: Xuan Zhuo
Thank you Xuan!
Acked-by: Magnus Karlsson
> ---
> net/xdp/xsk.c | 16 +---
> net/xdp/xsk_queue.h | 6 ++
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 0df8651..22e35e9 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -211,6 +211,14 @@ static int __xsk_rcv(struct xdp_sock *xs, struct
> xdp_buff *xdp, u32 len,
> return 0;
> }
>
> +static bool xsk_tx_writeable(struct xdp_sock *xs)
> +{
> + if (xskq_cons_present_entries(xs->tx) > xs->tx->nentries / 2)
> + return false;
> +
> + return true;
> +}
> +
> static bool xsk_is_bound(struct xdp_sock *xs)
> {
> if (READ_ONCE(xs->state) == XSK_BOUND) {
> @@ -296,7 +304,8 @@ void xsk_tx_release(struct xsk_buff_pool *pool)
> rcu_read_lock();
> list_for_each_entry_rcu(xs, >xsk_tx_list, tx_list) {
> __xskq_cons_release(xs->tx);
> - xs->sk.sk_write_space(>sk);
> + if (xsk_tx_writeable(xs))
> + xs->sk.sk_write_space(>sk);
> }
> rcu_read_unlock();
> }
> @@ -499,7 +508,8 @@ static int xsk_generic_xmit(struct sock *sk)
>
> out:
> if (sent_frame)
> - sk->sk_write_space(sk);
> + if (xsk_tx_writeable(xs))
> + sk->sk_write_space(sk);
>
> mutex_unlock(>mutex);
> return err;
> @@ -556,7 +566,7 @@ static __poll_t xsk_poll(struct file *file, struct socket
> *sock,
>
> if (xs->rx && !xskq_prod_is_empty(xs->rx))
> mask |= EPOLLIN | EPOLLRDNORM;
> - if (xs->tx && !xskq_cons_is_full(xs->tx))
> + if (xs->tx && xsk_tx_writeable(xs))
> mask |= EPOLLOUT | EPOLLWRNORM;
>
> return mask;
> diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
> index b936c46..b655004 100644
> --- a/net/xdp/xsk_queue.h
> +++ b/net/xdp/xsk_queue.h
> @@ -307,6 +307,12 @@ static inline bool xskq_cons_is_full(struct xsk_queue *q)
> q->nentries;
> }
>
> +static inline __u64 xskq_cons_present_entries(struct xsk_queue *q)
> +{
> + /* No barriers needed since data is not accessed */
> + return READ_ONCE(q->ring->producer) - READ_ONCE(q->ring->consumer);
> +}
> +
> /* Functions for producers */
>
> static inline u32 xskq_prod_nb_free(struct xsk_queue *q, u32 max)
> --
> 1.8.3.1
>
Re: [PATCH bpf v2 1/2] xsk: replace datagram_poll by sock_poll_wait
On Wed, Nov 25, 2020 at 7:49 AM Xuan Zhuo wrote:
>
> datagram_poll will judge the current socket status (EPOLLIN, EPOLLOUT)
> based on the traditional socket information (eg: sk_wmem_alloc), but
> this does not apply to xsk. So this patch uses sock_poll_wait instead of
> datagram_poll, and the mask is calculated by xsk_poll.
>
> Signed-off-by: Xuan Zhuo
> ---
> net/xdp/xsk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Magnus Karlsson
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index b014197..0df8651 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -534,11 +534,13 @@ static int xsk_sendmsg(struct socket *sock, struct
> msghdr *m, size_t total_len)
> static __poll_t xsk_poll(struct file *file, struct socket *sock,
> struct poll_table_struct *wait)
> {
> - __poll_t mask = datagram_poll(file, sock, wait);
> + __poll_t mask = 0;
> struct sock *sk = sock->sk;
> struct xdp_sock *xs = xdp_sk(sk);
> struct xsk_buff_pool *pool;
>
> + sock_poll_wait(file, sock, wait);
> +
> if (unlikely(!xsk_is_bound(xs)))
> return mask;
>
> --
> 1.8.3.1
>
How to Unblock IP Address of Email Client in Linux iptables Firewall in Linux Mail Server
Subject: How to Unblock IP Address of Email Client in Linux iptables Firewall in Linux Mail Server Good day from Singapore, I am an IT consultant in Singapore. Today, Black Friday 27 November 2020, my client Donald Trump (fictitious name used) informed me that he cannot send and receive emails using his home Wi-Fi connection. But he could send and receive emails using his mobile phone 4G connection. Apparently, the public IP address of his home internet connection was blocked. The IP address is 666.666.666.666 (fictitious IP address used). I checked the Fortigate 100D firewall but it was not blocked there. Then I proceed to check the Linux iptables firewall on my client's Linux mail server. I login/putty/ssh into mail.teo-en-ming-corp.com.sg, which is my client's Linux mail server. I executed the following command: # iptables -S | grep 666.666.666.666 The output is: -A DENYIN -s 666.666.666.666/32 ! -i lo -j DROP -A DENYOUT -d 666.666.666.666/32 ! -o lo -j LOGDROPOUT I proceeded to delete the above 2 Linux iptables firewall rules which blocked the IP address 666.666.666.666, using the following commands: # iptables -D DENYIN -s 666.666.666.666/32 ! -i lo -j DROP # iptables -D DENYOUT -d 666.666.666.666/32 ! -o lo -j LOGDROPOUT Then I run the following command again to make sure the IP address has been unblocked. # iptables -S | grep 666.666.666.666 There should be no output, confirming that the IP address has been unblocked. Now my client Donald Trump is able to send and receive emails using his home Wi-fi connection successfully. The author, Mr. Turritopsis Dohrnii Teo En Ming, 42 years as of 27 Nov 2020 Friday, is a TARGETED INDIVIDUAL (TI) living in Singapore. Reference Guide: How To List and Delete Iptables Firewall Rules Link: https://www.digitalocean.com/community/tutorials/how-to-list-and-delete-iptables-firewall-rules -- -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Re: [PATCH v2 tip/core/rcu 6/6] srcu: Document polling interfaces for Tree SRCU grace periods
On 11/21/2020 6:29 AM, paul...@kernel.org wrote: From: "Paul E. McKenney" This commit adds requirements documentation for the get_state_synchronize_srcu(), start_poll_synchronize_srcu(), and poll_state_synchronize_srcu() functions. Link: https://lore.kernel.org/rcu/20201112201547.gf3365...@moria.home.lan/ Reported-by: Kent Overstreet Signed-off-by: Paul E. McKenney --- Reviewed-by: Neeraj Upadhyay Thanks Neeraj Documentation/RCU/Design/Requirements/Requirements.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 1e3df77..2dce79d 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2600,6 +2600,24 @@ also includes DEFINE_SRCU(), DEFINE_STATIC_SRCU(), and init_srcu_struct() APIs for defining and initializing ``srcu_struct`` structures. +More recently, the SRCU API has added polling interfaces: + +#. start_poll_synchronize_srcu() returns a cookie identifying + the completion of a future SRCU grace period and ensures + that this grace period will be started. +#. poll_state_synchronize_srcu() returns ``true`` iff the + specified cookie corresponds to an already-completed + SRCU grace period. +#. get_state_synchronize_srcu() returns a cookie just like + start_poll_synchronize_srcu() does, but differs in that + it does nothing to ensure that any future SRCU grace period + will be started. + +These functions are used to avoid unnecessary SRCU grace periods in +certain types of buffer-cache algorithms having multi-stage age-out +mechanisms. The idea is that by the time the block has aged completely +from the cache, an SRCU grace period will be very likely to have elapsed. + Tasks RCU ~ -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote: > On Fri, 27 Nov 2020, Pkshih wrote: > > > > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'. > > > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote: > > > Also strip out other duplicates from driver specific headers. > > > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter > > > uses some defines from the former. It avoids issues like: > > > > > > from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5: > > > drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: > > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean > > > ‘RTK_MAX_RX_DESC_NUM’? > > > 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM); > > > | ^~~~ > > > > > > Fixes the following W=1 kernel build warning(s): > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous > > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes] > > > 1488 | int rtw_pci_probe(struct pci_dev *pdev, > > > | ^ > > > drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous > > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes] > > > 1568 | void rtw_pci_remove(struct pci_dev *pdev) > > > | ^~ > > > drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous > > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes] > > > 1590 | void rtw_pci_shutdown(struct pci_dev *pdev) > > > | ^~~~ > > > > > > Cc: Yan-Hsuan Chuang > > > Cc: Kalle Valo > > > Cc: "David S. Miller" > > > Cc: Jakub Kicinski > > > Cc: linux-wirel...@vger.kernel.org > > > Cc: net...@vger.kernel.org > > > Signed-off-by: Lee Jones > > > --- > > > drivers/net/wireless/realtek/rtw88/pci.h | 8 > > > drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 + > > > drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 + > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 > > > drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 + > > > drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 + > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 > > > 9 files changed, 12 insertions(+), 16 deletions(-) > > > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h > > > b/drivers/net/wireless/realtek/rtw88/pci.h > > > index ca17aa9cf7dc7..cda56919a5f0f 100644 > > > --- a/drivers/net/wireless/realtek/rtw88/pci.h > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h > > > @@ -5,6 +5,8 @@ > > > #ifndef __RTK_PCI_H_ > > > #define __RTK_PCI_H_ > > > > > > +#include "main.h" > > > + > > > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c. > > You mean instead of in pci.h? > > Surely that's a hack. > I mean don't include main.h in pci.h, but include both of them in each of rtw8e.c. +#include "main.h" +#include "pci.h" --- Ping-Ke
Re: [PATCH RESEND v6 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
On Mon, 23 Nov 2020, Matti Vaittinen wrote: > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are > mainly used to power the R-Car series processors. > > Signed-off-by: Matti Vaittinen > --- > drivers/mfd/Kconfig | 11 > drivers/mfd/Makefile | 1 + > drivers/mfd/rohm-bd9576.c| 108 +++ > include/linux/mfd/rohm-bd957x.h | 59 + > include/linux/mfd/rohm-generic.h | 2 + > 5 files changed, 181 insertions(+) > create mode 100644 drivers/mfd/rohm-bd9576.c > create mode 100644 include/linux/mfd/rohm-bd957x.h Looks like a possible candidate for "simple-mfd-i2c". Could you look into that please? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 2/2] media: dt-bindings: media: i2c: Add IMX300 CMOS sensor binding
Hi AngeloGioacchino,
On 29.10.2020 20:29, khol...@gmail.com wrote:
From: AngeloGioacchino Del Regno
Add YAML device tree binding for IMX300 CMOS image sensor, and
the relevant MAINTAINERS entries.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/media/i2c/sony,imx300.yaml | 112 ++
MAINTAINERS | 7 ++
2 files changed, 119 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
new file mode 100644
index ..8f1d795f8072
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony 1/2.3-Inch 8Mpixel Stacked CMOS Digital Image Sensor
You said this is an 8 MP sensor,
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |-
+ The Sony IMX300 is a 1/2.3-inch Stacked CMOS (Exmor-RS) digital image
+ sensor with a pixel size of 1.08um and an active array size of
+ 5948H x 4140V. It is programmable through I2C interface at address 0x10.
- but 5948H x 4140V is more than 8 MP.
Thanks,
Andrey
+ Image data is sent through MIPI CSI-2, which is configured as either 2 or
+ 4 data lanes.
+
+properties:
+ compatible:
+const: sony,imx300
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ vdig-supply:
+description:
+ Digital I/O voltage supply, 1.15-1.20 volts
+
+ vana-supply:
+description:
+ Analog voltage supply, 2.2 volts
+
+ vddl-supply:
+description:
+ Digital core voltage supply, 1.8 volts
+
+ reset-gpios:
+description: |-
+ Reference to the GPIO connected to the xclr pin, if any.
+ Must be released (set high) after all supplies are applied.
+
+ # See ../video-interfaces.txt for more details
+ port:
+type: object
+properties:
+ endpoint:
+type: object
+
+properties:
+ data-lanes:
+description: |-
+ The sensor supports either two-lane, or four-lane operation,
+ but the driver currently supports only four-lane.
+items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ clock-noncontinuous: true
+
+ link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description:
+ Allowed data bus frequencies. The driver currently needs
+ to switch between 78000 and 48000 Hz in order to
+ guarantee functionality of all modes.
+
+required:
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vana-supply
+ - vdig-supply
+ - vddl-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+imx300: sensor@10 {
+compatible = "sony,imx300";
+reg = <0x10>;
+clocks = <_xclk>;
+vana-supply = <_vana>; /* 2.2v */
+vdig-supply = <_vdig>; /* 1.2v */
+vddl-supply = <_vddl>; /* 1.8v */
+
+port {
+imx300_0: endpoint {
+remote-endpoint = <_ep>;
+data-lanes = <0 1 2 3>;
+clock-noncontinuous;
+link-frequencies = /bits/ 64 <78000 48000>;
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c66710dd7e0a..21ba41db0063 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16279,6 +16279,13 @@ T: git git://linuxtv.org/media_tree.git
F:Documentation/devicetree/bindings/media/i2c/imx290.txt
F:drivers/media/i2c/imx290.c
+SONY IMX300 SENSOR DRIVER
+M: AngeloGioacchino Del Regno
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
+F: drivers/media/i2c/imx300.c
+
SONY IMX319 SENSOR DRIVER
M:Bingbu Cao
L:linux-me...@vger.kernel.org
Re: [PATCH 2/2] arm64: dts: mediatek: mt8516: add efuse node
On 16/10/2020 19:18, Fabien Parent wrote:
Add node to support e-fuses on MT8516
Signed-off-by: Fabien Parent
---
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 7 +++
1 file changed, 7 insertions(+)
Applied to v5.10-next/dts64
Thanks!
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index 89af661e7f63..18ddea519be2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -237,6 +237,13 @@ pio: pinctrl@1000b000 {
interrupts = ;
};
+ efuse: efuse@10009000 {
+ compatible = "mediatek,mt8516-efuse", "mediatek,efuse";
+ reg = <0 0x10009000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
pwrap: pwrap@1000f000 {
compatible = "mediatek,mt8516-pwrap";
reg = <0 0x1000f000 0 0x1000>;
[RFC 1/2] dt-bindings: thermal: sprd: Add virtual thermal documentation
From: "jeson.gao"
virtual thermal node definition description in dts file
Signed-off-by: jeson.gao
---
.../thermal/sprd-virtual-thermal.yaml | 38 +++
1 file changed, 38 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
diff --git
a/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
b/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
new file mode 100644
index ..3e3d2282e2a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/sprd-virtual-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum virtual thermal driver bindings
+
+maintainers:
+ - Yunxiao Gao
+
+properties:
+ compatible:
+const: sprd,virtual-thermal
+
+ reg:
+description: specify the virtual sensor id.
+maxItems: 1
+
+ thmzone-names:
+description: specify per-core thermal zone name.
+
+required:
+ - compatible
+ - reg
+ - thmzone-names
+
+additionalProperties: false
+
+examples:
+ - |
+virtual_sensor: virtual-sensor@1 {
+ compatible = "sprd,virtual-thermal";
+ reg = <1>;
+ thmzone-names = "ank0-thmzone","ank1-thmzone","ank2-thmzone",
+
"ank3-thmzone","ank4-thmzone","ank5-thmzone","prometheus6-tzone0",
+ "prometheus6-tzone1","prometheus7-thmzone";
+};
--
2.28.0
[RFC 2/2] thermal: sprd: Add virtual thermal driver
From: "jeson.gao"
IPA need a temperature of the whole CPU zone for thermal-cpufreq-0
and thermal-cpufreq-1 cooling device but the real sensor is placed
near per-core on sprd platform,so adding this driver to register a
virtual sensor,it will polling the temperature of per-core and find
the highest temperature as the current temperature of the whole cpu
zone for IPA using.
Signed-off-by: jeson.gao
---
drivers/thermal/Kconfig| 9 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/sprd_virtual_thermal.c | 213 +
3 files changed, 223 insertions(+)
create mode 100644 drivers/thermal/sprd_virtual_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 7edc8dc6bbab..b3d392846f69 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -500,6 +500,15 @@ config SPRD_THERMAL
Support for the Spreadtrum thermal sensor driver in the Linux thermal
framework.
+config SPRD_VIRTUAL_THERMAL
+ tristate "sprd virtual thermal"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on SPRD_THERMAL
+ help
+ Say Y here to support virtual thermal driver
+ We can use it to find the highest temperature from 8 per core sensor
+ as the current temperature of the whole cpu zone.
+
config KHADAS_MCU_FAN_THERMAL
tristate "Khadas MCU controller FAN cooling support"
depends on OF || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index b64dd50a6629..f4aecfff3703 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -61,4 +61,5 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
+obj-$(CONFIG_SPRD_VIRTUAL_THERMAL) += sprd_virtual_thermal.o
obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
diff --git a/drivers/thermal/sprd_virtual_thermal.c
b/drivers/thermal/sprd_virtual_thermal.c
new file mode 100644
index ..db4d6eca2356
--- /dev/null
+++ b/drivers/thermal/sprd_virtual_thermal.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2020 Unisoc Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct virtual_thm {
+ int id;
+ struct device *dev;
+ struct thermal_zone_device *thm_dev;
+};
+
+struct real_tz_list {
+ int temp;
+ struct thermal_zone_device *tz_dev;
+};
+
+struct virtual_thm_data {
+ int nr_thm;
+ struct real_tz_list *tz_list;
+ struct virtual_thm *vir_thm;
+};
+
+static int virtual_thm_get_temp(void *devdata, int *temp)
+{
+ int i, ret = 0;
+ int max_temp = 0;
+ struct thermal_zone_device *tz = NULL;
+ struct real_tz_list *tz_list = NULL;
+ struct virtual_thm_data *thm_data = devdata;
+ struct device *dev;
+
+ if (!thm_data || !temp)
+ return -EINVAL;
+
+ dev = thm_data->vir_thm->dev;
+ for (i = 0; i < thm_data->nr_thm; i++) {
+ tz_list = _data->tz_list[i];
+ tz = tz_list->tz_dev;
+ if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
+ return -EINVAL;
+ ret = tz->ops->get_temp(tz, _list->temp);
+ if (ret) {
+ dev_err(dev, "fail to get temp\n");
+ return ret;
+ }
+ max_temp = max(max_temp, tz_list->temp);
+ }
+ *temp = max_temp;
+
+ return ret;
+}
+
+static void virtual_thm_unregister(struct platform_device *pdev)
+{
+ struct virtual_thm_data *data = platform_get_drvdata(pdev);
+ struct virtual_thm *vir_thm = data->vir_thm;
+
+ devm_thermal_zone_of_sensor_unregister(>dev, vir_thm->thm_dev);
+}
+
+static const struct thermal_zone_of_device_ops virtual_thm_ops = {
+ .get_temp = virtual_thm_get_temp,
+};
+
+static int virtual_thm_register(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct virtual_thm_data *data = platform_get_drvdata(pdev);
+ struct virtual_thm *vir_thm = data->vir_thm;
+
+ vir_thm->thm_dev = devm_thermal_zone_of_sensor_register(dev,
+ vir_thm->id, data,
+ _thm_ops);
+ if (IS_ERR_OR_NULL(vir_thm->thm_dev))
+ return -ENODEV;
+ thermal_zone_device_update(vir_thm->thm_dev, THERMAL_EVENT_UNSPECIFIED);
+
+ return 0;
+}
+
+static int get_thm_zone_counts(struct device *dev)
+{
+ int count;
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ dev_err(dev, "device node not found\n");
+ return -EINVAL;
+ }
+
+ count = of_property_count_strings(np, "thmzone-names");
+
[git pull] drm fixes for 5.10-rc6
Hi Linus, Bit of a delay as fd.o anongit was acting up a bit today, hopefully it stays up this time. Unfortunately this has a bit of thanksgiving stuffing in it, as it a bit larger (at least the vc4 patches) than I like at this point in time. The main thing is it has a bunch of regressions fixes for reports in the last couple of weeks, ast, nouveau and the amdgpu ttm init fix, along with the usual selection of amdgpu and i915 fixes. The vc4 fixes are a few but they are fixes and the nastiest one is a fix for when you have a 2.4Ghz Wifi and a HDMI signal with a clock in that range and there isn't enough shielding and interference happen between the two, the fix adjusts the mode clock to try and avoid the wifi channels in that case. Hopefully you can merge this between turkey slices, and next week should be quieter. Dave. drm-fixes-2020-11-27-1: drm fixes for 5.10-rc6 ast: - LUT loading regression fix nouveau: - relocations regression fix amdgpu: - ttm init oops fix - Runtime pm fix - SI UVD suspend/resume fix - HDCP fix for headless cards - Sienna Cichlid golden register update i915: - Fix Perf/OA workaround register corruption (Lionel) - Correct a comment statement in GVT (Yan) - Fix GT enable/disable iterrupts, including a race condition that prevented GPU to go idle (Chris) - Free stale request on destroying the virtual engine (Chris) exynos: - config dependency fix mediatek: - unused var removal - horizonal front/back porch formula fix vc4: - wifi and hdmi interference fix - mode rejection fixes - use after free fix - cleanup some code The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18: Linux 5.10-rc5 (2020-11-22 15:36:08 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-27-1 for you to fetch changes up to 9595930db4bb91433607441a5f26d90e9c6e34eb: Merge tag 'drm-misc-fixes-2020-11-26' of ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes (2020-11-27 09:39:51 +1000) drm fixes for 5.10-rc6 ast: - LUT loading regression fix nouveau: - relocations regression fix amdgpu: - ttm init oops fix - Runtime pm fix - SI UVD suspend/resume fix - HDCP fix for headless cards - Sienna Cichlid golden register update i915: - Fix Perf/OA workaround register corruption (Lionel) - Correct a comment statement in GVT (Yan) - Fix GT enable/disable iterrupts, including a race condition that prevented GPU to go idle (Chris) - Free stale request on destroying the virtual engine (Chris) exynos: - config dependency fix mediatek: - unused var removal - horizonal front/back porch formula fix vc4: - wifi and hdmi interference fix - mode rejection fixes - use after free fix - cleanup some code CK Hu (1): drm/mediatek: dsi: Modify horizontal front/back porch byte formula Chris Wilson (4): drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock drm/i915/gt: Don't cancel the interrupt shadow too early drm/i915/gt: Free stale request on destroying the virtual engine Dave Airlie (5): Merge tag 'amd-drm-fixes-5.10-2020-11-25' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2020-11-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'exynos-drm-fixes-for-v5.10-rc6' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Merge tag 'mediatek-drm-fixes-5.10' of https://git.kernel.org/.../chunkuang.hu/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-11-26' of ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes Enric Balletbo i Serra (1): drm/mediatek: mtk_dpi: Fix unused variable 'mtk_dpi_encoder_funcs' Kenneth Feng (1): drm/amd/amdgpu: fix null pointer in runtime pm Krzysztof Kozlowski (1): drm/exynos: depend on COMMON_CLK to fix compile tests Likun Gao (1): drm/amdgpu: update golden setting for sienna_cichlid Lionel Landwerlin (1): drm/i915/perf: workaround register corruption in OATAILPTR Matti Hamalainen (1): drm/nouveau: fix relocations applying logic and a double-free Maxime Ripard (11): drm/vc4: hdmi: Make sure our clock rate is within limits drm/vc4: hdmi: Block odd horizontal timings drm/vc4: kms: Switch to drmm_add_action_or_reset drm/vc4: kms: Remove useless define drm/vc4: kms: Rename NUM_CHANNELS drm/vc4: kms: Split the HVS muxing check in a separate function drm/vc4: kms: Document the muxing corner cases dt-bindings: display: Add a property to deal with WiFi coexistence drm/vc4: hdmi: Disable Wifi Frequencies drm/vc4: kms: Store the unassigned channel list in the state drm/vc4: kms: Don't disable the muxing of an active CRTC Rodrigo Siqueira (1):
[PATCH] mips: lib: uncached: fix uninitialized variable 'sp'
When building mips tinyconfig with clang the following warning show up:
/tmp/arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to
silence this warning
register long sp __asm__("$sp");
^
= 0
Rework to make an explicit inline move.
Signed-off-by: Anders Roxell
---
arch/mips/lib/uncached.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
index 09d5deea747f..21a4b94a0558 100644
--- a/arch/mips/lib/uncached.c
+++ b/arch/mips/lib/uncached.c
@@ -37,10 +37,11 @@
*/
unsigned long run_uncached(void *func)
{
- register long sp __asm__("$sp");
register long ret __asm__("$2");
long lfunc = (long)func, ufunc;
long usp;
+ long sp;
+ asm ("move %0, $sp" : "=r" (sp));
if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
usp = CKSEG1ADDR(sp);
--
2.29.2
[PATCH] mips: fix Section mismatch in reference
When building mips tinyconfig with clang the following error show up:
WARNING: modpost: vmlinux.o(.text+0x1940c): Section mismatch in reference from
the function r4k_cache_init() to the function .init.text:loongson3_sc_init()
The function r4k_cache_init() references
the function __init loongson3_sc_init().
This is often because r4k_cache_init lacks a __init
annotation or the annotation of loongson3_sc_init is wrong.
Remove marked __init from function loongson3_sc_init(),
mips_sc_probe_cm3(), and mips_sc_probe().
Signed-off-by: Anders Roxell
---
arch/mips/mm/c-r4k.c | 2 +-
arch/mips/mm/sc-mips.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 99521764c75b..4f976d687ab0 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1609,7 +1609,7 @@ static void __init loongson2_sc_init(void)
c->options |= MIPS_CPU_INCLUSIVE_CACHES;
}
-static void __init loongson3_sc_init(void)
+static void loongson3_sc_init(void)
{
struct cpuinfo_mips *c = _cpu_data;
unsigned int config2, lsize;
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index dd0a5becaabd..06ec304ad4d1 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -146,7 +146,7 @@ static inline int mips_sc_is_activated(struct cpuinfo_mips
*c)
return 1;
}
-static int __init mips_sc_probe_cm3(void)
+static int mips_sc_probe_cm3(void)
{
struct cpuinfo_mips *c = _cpu_data;
unsigned long cfg = read_gcr_l2_config();
@@ -180,7 +180,7 @@ static int __init mips_sc_probe_cm3(void)
return 0;
}
-static inline int __init mips_sc_probe(void)
+static inline int mips_sc_probe(void)
{
struct cpuinfo_mips *c = _cpu_data;
unsigned int config1, config2;
--
2.29.2
Re: [PATCH v3] lan743x: fix for potential NULL pointer dereference with bare card
Hi Sven. > Hi Jakub, Sergej, > > On Tue, Nov 3, 2020 at 8:41 PM Jakub Kicinski wrote: > > On Mon, 2 Nov 2020 01:35:55 +0300 Sergej Bauer wrote: > > > This is the 3rd revision of the patch fix for potential null pointer > > > dereference with lan743x card. > > > > Applied, thanks! > > I noticed that this went into net-next. Is there a chance that it could also > be added to net? It's a real issue on 5.9, and the patch applies cleanly > there. It's my mistake - I missed pointing of stable branch. Should I resend the patch (with tag Cc:sta...@vger.kernel.org)? Regards, Sergej.
Re: [PATCH 1/3] dt-bindings: arm64: dts: mediatek: Add mt8167-pumpkin board
On 27/10/2020 20:48, Fabien Parent wrote: Add binding documentation for the MT8167 Pumpkin board. Signed-off-by: Fabien Parent --- Documentation/devicetree/bindings/arm/mediatek.yaml | 4 1 file changed, 4 insertions(+) All three patches applied to v5.10-next/dts64 Thanks! diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 30908963ae26..5c772b937efc 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -84,6 +84,10 @@ properties: - enum: - mediatek,mt8135-evbp1 - const: mediatek,mt8135 + - items: + - enum: + - mediatek,mt8167-pumpkin + - const: mediatek,mt8167 - description: Google Elm (Acer Chromebook R13) items: - const: google,elm-rev8
Re: [PATCH 1/1] perf diff: fix error return value in __cmd_diff()
Hi everybody:
Can any one review it?
On 2020/11/24 18:36, Zhen Lei wrote:
> An appropriate return value should be set on the failed path.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
> ---
> tools/perf/builtin-diff.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 584e2e1a3793..cefc71506409 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -1222,8 +1222,10 @@ static int __cmd_diff(void)
> if (compute == COMPUTE_STREAM) {
> d->evlist_streams = evlist__create_streams(
> d->session->evlist, 5);
> - if (!d->evlist_streams)
> + if (!d->evlist_streams) {
> + ret = -ENOMEM;
> goto out_delete;
> + }
> }
> }
>
>
[PATCH] riscv/stacktrace: fix stackframe without ra on the top
When a function doesn't have a callee, then it will not push ra
into the stack, such as lkdtm_BUG() function:
addisp,sp,-16
sd s0,8(sp)
addis0,sp,16
ebreak
Then we use pt_regs as a parameter to walk_stackframe(), for the
struct stackframe use {fp,ra} to get information from stack, it
will get the wrong value. And the call trace will be:
[] lkdtm_BUG+0x6/0x8
---[ end trace 18da3fbdf08e25d5 ]---
It should be that:
[] lkdtm_BUG+0x6/0x8
[] lkdtm_do_action+0x14/0x1c
[] direct_entry+0xc0/0x10a
[] full_proxy_write+0x42/0x6a
[] vfs_write+0x7e/0x214
[] ksys_write+0x98/0xc0
[] sys_write+0xe/0x16
[] ret_from_syscall+0x0/0x2
---[ end trace 61917f3d9a9fadcd ]---
Signed-off-by: Chen Huang
---
arch/riscv/kernel/stacktrace.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 595342910c3f..d1d4c18335c4 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -57,7 +57,14 @@ void notrace walk_stackframe(struct task_struct *task,
struct pt_regs *regs,
/* Unwind stack frame */
frame = (struct stackframe *)fp - 1;
sp = fp;
- fp = frame->fp;
+ if (regs && (frame->fp & 0x7) && (pc == regs->epc)) {
+ fp = frame->ra;
+ pc = regs->ra;
+ continue;
+ } else {
+ fp = frame->fp;
+ }
+
pc = ftrace_graph_ret_addr(current, NULL, frame->ra,
(unsigned long *)(fp - 8));
}
--
2.17.1
Re: [REGRESSION] omapdrm/N900 display broken
On 25/11/2020 11:07, Daniel Vetter wrote: >> Laurent, does this ring any bells? The WARN comes in >> drm_atomic_bridge_chain_enable() when >> drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge. >> >> I'm not sure why the bridge state would not be there. > > Lack of state on first modeset usually means your > drm_mode_config_reset didn't create one. Or whatever it is you're > using. I didn't look whether you're wiring this up correctly or not. > We might even want to add a ->reset function to > drm_private_state_funcs to make this work for everyone. The bridge driver set atomic_enable and atomic_disable, but no other atomic funcs. It was supposed to set the legacy enable & disable. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 1/2] dt-bindings: dma: mtk-apdma: add bindings for MT8516 SOC
Hi Vinod, On 19/10/2020 23:16, Rob Herring wrote: On Thu, 15 Oct 2020 14:33:14 +0200, Fabien Parent wrote: Add bindings to APDMA for MT8516 SoC. MT8516 is compatible with MT6577. Signed-off-by: Fabien Parent --- Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 1 + 1 file changed, 1 insertion(+) Acked-by: Rob Herring Will you take this patch through your tree or do you prefer that I take it. Regards, Matthias
Re: [PATCH 1/2] phy: rockchip: set pulldown for strobe line in dts
Hi Chris,
Before a new property "enable-strobe-pulldown" is introduced in the code
a change to the documents must be made in a separate patch.
(rockchip-emmc-phy.txt)
./scripts/checkpatch.pl --strict
On 11/27/20 4:33 AM, Chris Ruehl wrote:
> This patch add support to set the internal pulldown via dt property
> and allow simplify the board design for the trace from emmc-phy to
> the eMMC chipset.
> Default to not set the pull-down.
>
> This patch was inspired from the 4.4 tree of the
> Rockchip SDK, where it is enabled unconditional.
> The patch had been tested with our rk3399 customized board.
>
> Signed-off-by: Chris Ruehl
> ---
> drivers/phy/rockchip/phy-rockchip-emmc.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
> b/drivers/phy/rockchip/phy-rockchip-emmc.c
> index 2dc19ddd120f..d9bc45828f74 100644
> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
> @@ -67,6 +67,10 @@
> #define PHYCTRL_OTAPDLYENA_SHIFT 0xb
> #define PHYCTRL_OTAPDLYSEL_MASK 0xf
> #define PHYCTRL_OTAPDLYSEL_SHIFT 0x7
> +#define PHYCTRL_REN_STRB_DISABLE 0x0
> +#define PHYCTRL_REN_STRB_ENABLE 0x1
> +#define PHYCTRL_REN_STRB_MASK0x1
> +#define PHYCTRL_REN_STRB_SHIFT 0x9
align with extra TAB ?
check TAB size
>
> #define PHYCTRL_IS_CALDONE(x) \
> x) >> PHYCTRL_CALDONE_SHIFT) & \
> @@ -80,6 +84,7 @@ struct rockchip_emmc_phy {
> struct regmap *reg_base;
> struct clk *emmcclk;
> unsigned int drive_impedance;
> + unsigned int enable_strobe_pulldown;
> };
>
> static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
> @@ -295,6 +300,13 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
> PHYCTRL_OTAPDLYSEL_MASK,
> PHYCTRL_OTAPDLYSEL_SHIFT));
>
> + /* Internal pull-down for strobe line */
> + regmap_write(rk_phy->reg_base,
> + rk_phy->reg_offset + GRF_EMMCPHY_CON2,
CHECK: Alignment should match open parenthesis
#49: FILE: drivers/phy/rockchip/phy-rockchip-emmc.c:305:
+ regmap_write(rk_phy->reg_base,
+ rk_phy->reg_offset + GRF_EMMCPHY_CON2,
> + HIWORD_UPDATE(rk_phy->enable_strobe_pulldown,
> + PHYCTRL_REN_STRB_MASK,
> + PHYCTRL_REN_STRB_SHIFT));
CHECK: Alignment should match open parenthesis
#51: FILE: drivers/phy/rockchip/phy-rockchip-emmc.c:307:
+ HIWORD_UPDATE(rk_phy->enable_strobe_pulldown,
+ PHYCTRL_REN_STRB_MASK,
> +
> /* Power up emmc phy analog blocks */
> return rockchip_emmc_phy_power(phy, PHYCTRL_PDB_PWR_ON);
> }
> @@ -359,10 +371,14 @@ static int rockchip_emmc_phy_probe(struct
> platform_device *pdev)
> rk_phy->reg_offset = reg_offset;
> rk_phy->reg_base = grf;
> rk_phy->drive_impedance = PHYCTRL_DR_50OHM;
> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
>
> if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm", ))
> rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev,
> val);
>
> + if (of_property_read_bool(dev->of_node, "enable-strobe-pulldown"))
> + rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
> +
> generic_phy = devm_phy_create(dev, dev->of_node, );
> if (IS_ERR(generic_phy)) {
> dev_err(dev, "failed to create PHY\n");
>
[PATCH net-next 1/7] net: hns3: add support for RX completion checksum
In some cases (for example ip fragment), hardware will
calculate the checksum of whole packet in RX, and setup
the HNS3_RXD_L2_CSUM_B flag in the descriptor, so add
support to utilize this checksum.
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 21 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 7 +++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 +
3 files changed, 29 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 632ad42..5a706a3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2798,6 +2798,22 @@ static int hns3_gro_complete(struct sk_buff *skb, u32
l234info)
return 0;
}
+static void hns3_checksum_complete(struct hns3_enet_ring *ring,
+ struct sk_buff *skb, u32 l234info)
+{
+ __sum16 csum;
+
+ u64_stats_update_begin(>syncp);
+ ring->stats.csum_complete++;
+ u64_stats_update_end(>syncp);
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ csum = hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_L_M,
+ HNS3_RXD_L2_CSUM_L_S);
+ csum |= hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_H_M,
+ HNS3_RXD_L2_CSUM_H_S) << 8;
+ skb->csum = csum_unfold(csum);
+}
+
static void hns3_rx_checksum(struct hns3_enet_ring *ring, struct sk_buff *skb,
u32 l234info, u32 bd_base_info, u32 ol_info)
{
@@ -2812,6 +2828,11 @@ static void hns3_rx_checksum(struct hns3_enet_ring
*ring, struct sk_buff *skb,
if (!(netdev->features & NETIF_F_RXCSUM))
return;
+ if (l234info & BIT(HNS3_RXD_L2_CSUM_B)) {
+ hns3_checksum_complete(ring, skb, l234info);
+ return;
+ }
+
/* check if hardware has done checksum */
if (!(bd_base_info & BIT(HNS3_RXD_L3L4P_B)))
return;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 8d33652..40681a0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -82,6 +82,12 @@ enum hns3_nic_state {
#define HNS3_RXD_STRP_TAGP_S 13
#define HNS3_RXD_STRP_TAGP_M (0x3 << HNS3_RXD_STRP_TAGP_S)
+#define HNS3_RXD_L2_CSUM_B 15
+#define HNS3_RXD_L2_CSUM_L_S 4
+#define HNS3_RXD_L2_CSUM_L_M (0xff << HNS3_RXD_L2_CSUM_L_S)
+#define HNS3_RXD_L2_CSUM_H_S 24
+#define HNS3_RXD_L2_CSUM_H_M (0xff << HNS3_RXD_L2_CSUM_H_S)
+
#define HNS3_RXD_L2E_B 16
#define HNS3_RXD_L3E_B 17
#define HNS3_RXD_L4E_B 18
@@ -371,6 +377,7 @@ struct ring_stats {
u64 err_bd_num;
u64 l2_err;
u64 l3l4_csum_err;
+ u64 csum_complete;
u64 rx_multicast;
u64 non_reuse_pg;
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c30d5d3..3cca3c1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -55,6 +55,7 @@ static const struct hns3_stats hns3_rxq_stats[] = {
HNS3_TQP_STAT("err_bd_num", err_bd_num),
HNS3_TQP_STAT("l2_err", l2_err),
HNS3_TQP_STAT("l3l4_csum_err", l3l4_csum_err),
+ HNS3_TQP_STAT("csum_complete", csum_complete),
HNS3_TQP_STAT("multicast", rx_multicast),
HNS3_TQP_STAT("non_reuse_pg", non_reuse_pg),
};
--
2.7.4
[PATCH net-next 0/7] net: hns3: updates for -next
This series includes some updates for the HNS3 ethernet driver. #1~#6: add some updates related to the checksum offload. #7: add support for multiple TCs' MAC pauce mode. Huazhong Tan (6): net: hns3: add support for RX completion checksum net: hns3: add support for TX hardware checksum offload net: hns3: remove unsupported NETIF_F_GSO_UDP_TUNNEL_CSUM net: hns3: add udp tunnel checksum segmentation support net: hns3: add more info to hns3_dbg_bd_info() net: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug() Yonglong Liu (1): net: hns3: keep MAC pause mode when multiple TCs are enabled drivers/net/ethernet/hisilicon/hns3/hnae3.h| 7 +- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 62 -- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 131 - drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 21 +++- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 3 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 23 +++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 4 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 3 +- 10 files changed, 207 insertions(+), 52 deletions(-) -- 2.7.4
[PATCH net-next 6/7] net: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug()
For the device whose version is above V3(include V3), the hardware
can do checksum offload for the non-tunnel udp packet, who has
a dest port as the IANA assigned. So add a check for devcie's verion
in hns3_tunnel_csum_bug().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 07bdb3d5..b51bf61 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -828,8 +828,16 @@ static int hns3_get_l4_protocol(struct sk_buff *skb, u8
*ol4_proto,
*/
static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
{
+ struct hns3_nic_priv *priv = netdev_priv(skb->dev);
+ struct hnae3_ae_dev *ae_dev = pci_get_drvdata(priv->ae_handle->pdev);
union l4_hdr_info l4;
+ /* device version above V3(include V3), the hardware can
+* do this checksum offload.
+*/
+ if (ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V3)
+ return false;
+
l4.hdr = skb_transport_header(skb);
if (!(!skb->encapsulation &&
--
2.7.4
[PATCH net-next 2/7] net: hns3: add support for TX hardware checksum offload
For the device that supports TX hardware checksum, the hardware
can calculate the checksum from the start and fill the checksum
to the offset position, which reduces the operations of
calculating the type and header length of L3/L4. So add this
feature for the HNS3 ethernet driver.
The previous simple BD description is unsuitable, rename it as
HW TX CSUM.
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 6 +--
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 6 ++-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 62 ++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 10 +++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 2 +-
8 files changed, 74 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index f6fac24..0632607 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -81,7 +81,7 @@ enum HNAE3_DEV_CAP_BITS {
HNAE3_DEV_SUPPORT_FD_FORWARD_TC_B,
HNAE3_DEV_SUPPORT_PTP_B,
HNAE3_DEV_SUPPORT_INT_QL_B,
- HNAE3_DEV_SUPPORT_SIMPLE_BD_B,
+ HNAE3_DEV_SUPPORT_HW_TX_CSUM_B,
HNAE3_DEV_SUPPORT_TX_PUSH_B,
HNAE3_DEV_SUPPORT_PHY_IMP_B,
HNAE3_DEV_SUPPORT_TQP_TXRX_INDEP_B,
@@ -113,8 +113,8 @@ enum HNAE3_DEV_CAP_BITS {
#define hnae3_dev_int_ql_supported(hdev) \
test_bit(HNAE3_DEV_SUPPORT_INT_QL_B, (hdev)->ae_dev->caps)
-#define hnae3_dev_simple_bd_supported(hdev) \
- test_bit(HNAE3_DEV_SUPPORT_SIMPLE_BD_B, (hdev)->ae_dev->caps)
+#define hnae3_dev_hw_csum_supported(hdev) \
+ test_bit(HNAE3_DEV_SUPPORT_HW_TX_CSUM_B, (hdev)->ae_dev->caps)
#define hnae3_dev_tx_push_supported(hdev) \
test_bit(HNAE3_DEV_SUPPORT_TX_PUSH_B, (hdev)->ae_dev->caps)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index a5ebca8..044552d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -178,6 +178,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
u32 tx_index, rx_index;
u32 q_num, value;
dma_addr_t addr;
+ u16 mss_hw_csum;
int cnt;
cnt = sscanf(_buf[8], "%u %u", _num, _index);
@@ -206,6 +207,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
tx_desc = >desc[tx_index];
addr = le64_to_cpu(tx_desc->addr);
+ mss_hw_csum = le16_to_cpu(tx_desc->tx.mss_hw_csum);
dev_info(dev, "TX Queue Num: %u, BD Index: %u\n", q_num, tx_index);
dev_info(dev, "(TX)addr: %pad\n", );
dev_info(dev, "(TX)vlan_tag: %u\n", le16_to_cpu(tx_desc->tx.vlan_tag));
@@ -225,7 +227,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
dev_info(dev, "(TX)paylen: %u\n", le32_to_cpu(tx_desc->tx.paylen));
dev_info(dev, "(TX)vld_ra_ri: %u\n",
le16_to_cpu(tx_desc->tx.bdtp_fe_sc_vld_ra_ri));
- dev_info(dev, "(TX)mss: %u\n", le16_to_cpu(tx_desc->tx.mss));
+ dev_info(dev, "(TX)mss_hw_csum: %u\n", mss_hw_csum);
ring = >ring[q_num + h->kinfo.num_tqps];
value = readl_relaxed(ring->tqp->io_base + HNS3_RING_RX_RING_TAIL_REG);
@@ -324,6 +326,8 @@ static void hns3_dbg_dev_caps(struct hnae3_handle *h)
test_bit(HNAE3_DEV_SUPPORT_PTP_B, caps) ? "yes" : "no");
dev_info(>pdev->dev, "support INT QL: %s\n",
test_bit(HNAE3_DEV_SUPPORT_INT_QL_B, caps) ? "yes" : "no");
+ dev_info(>pdev->dev, "support HW TX csum: %s\n",
+test_bit(HNAE3_DEV_SUPPORT_HW_TX_CSUM_B, caps) ? "yes" : "no");
}
static void hns3_dbg_dev_specs(struct hnae3_handle *h)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 5a706a3..e022bea 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1055,15 +1055,31 @@ static int hns3_handle_vtags(struct hns3_enet_ring
*tx_ring,
return 0;
}
+/* check if the hardware is capable of checksum offloading */
+static bool hns3_check_hw_tx_csum(struct sk_buff *skb)
+{
+ struct hns3_nic_priv *priv = netdev_priv(skb->dev);
+
+ /* Kindly note, due to backward compatibility of the TX descriptor,
+* HW checksum of the non-IP packets and GSO packets is handled at
+* different place in the following code
+*/
+ if (skb->csum_not_inet || skb_is_gso(skb) ||
+ !test_bit(HNS3_NIC_STATE_HW_TX_CSUM_ENABLE, >state))
+ return false;
+
+ return true;
+}
+
static int
[PATCH net-next 7/7] net: hns3: keep MAC pause mode when multiple TCs are enabled
From: Yonglong Liu
Bellow HNAE3_DEVICE_VERSION_V3, MAC pause mode just support one
TC, when enabled multiple TCs, force enable PFC mode.
HNAE3_DEVICE_VERSION_V3 can support MAC pause mode on multiple
TCs, so when enable multiple TCs, just keep MAC pause mode,
and enable PFC mode just according to the user settings.
Signed-off-by: Yonglong Liu
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 23 +-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index 54767b0..b1026cd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -715,7 +715,7 @@ static void hclge_tm_pg_info_init(struct hclge_dev *hdev)
}
}
-static void hclge_pfc_info_init(struct hclge_dev *hdev)
+static void hclge_update_fc_mode_by_dcb_flag(struct hclge_dev *hdev)
{
if (!(hdev->flag & HCLGE_FLAG_DCB_ENABLE)) {
if (hdev->fc_mode_last_time == HCLGE_FC_PFC)
@@ -733,6 +733,27 @@ static void hclge_pfc_info_init(struct hclge_dev *hdev)
}
}
+static void hclge_update_fc_mode(struct hclge_dev *hdev)
+{
+ if (!hdev->tm_info.pfc_en) {
+ hdev->tm_info.fc_mode = hdev->fc_mode_last_time;
+ return;
+ }
+
+ if (hdev->tm_info.fc_mode != HCLGE_FC_PFC) {
+ hdev->fc_mode_last_time = hdev->tm_info.fc_mode;
+ hdev->tm_info.fc_mode = HCLGE_FC_PFC;
+ }
+}
+
+static void hclge_pfc_info_init(struct hclge_dev *hdev)
+{
+ if (hdev->ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V3)
+ hclge_update_fc_mode(hdev);
+ else
+ hclge_update_fc_mode_by_dcb_flag(hdev);
+}
+
static void hclge_tm_schd_info_init(struct hclge_dev *hdev)
{
hclge_tm_pg_info_init(hdev);
--
2.7.4
[PATCH net-next 4/7] net: hns3: add udp tunnel checksum segmentation support
For the device who has the capability to handle udp tunnel
checksum segmentation, add support for it.
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 6 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 24 --
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 4 +++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 2 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 1 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 2 ++
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 1 +
8 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 0632607..78b4886 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -87,6 +87,7 @@ enum HNAE3_DEV_CAP_BITS {
HNAE3_DEV_SUPPORT_TQP_TXRX_INDEP_B,
HNAE3_DEV_SUPPORT_HW_PAD_B,
HNAE3_DEV_SUPPORT_STASH_B,
+ HNAE3_DEV_SUPPORT_UDP_TUNNEL_CSUM_B,
};
#define hnae3_dev_fd_supported(hdev) \
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index 044552d..cb0cc6d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -224,7 +224,8 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
dev_info(dev, "(TX)ol2_len: %u\n", tx_desc->tx.ol2_len);
dev_info(dev, "(TX)ol3_len: %u\n", tx_desc->tx.ol3_len);
dev_info(dev, "(TX)ol4_len: %u\n", tx_desc->tx.ol4_len);
- dev_info(dev, "(TX)paylen: %u\n", le32_to_cpu(tx_desc->tx.paylen));
+ dev_info(dev, "(TX)paylen_ol4cs: %u\n",
+le32_to_cpu(tx_desc->tx.paylen_ol4cs));
dev_info(dev, "(TX)vld_ra_ri: %u\n",
le16_to_cpu(tx_desc->tx.bdtp_fe_sc_vld_ra_ri));
dev_info(dev, "(TX)mss_hw_csum: %u\n", mss_hw_csum);
@@ -328,6 +329,9 @@ static void hns3_dbg_dev_caps(struct hnae3_handle *h)
test_bit(HNAE3_DEV_SUPPORT_INT_QL_B, caps) ? "yes" : "no");
dev_info(>pdev->dev, "support HW TX csum: %s\n",
test_bit(HNAE3_DEV_SUPPORT_HW_TX_CSUM_B, caps) ? "yes" : "no");
+ dev_info(>pdev->dev, "support UDP tunnel csum: %s\n",
+test_bit(HNAE3_DEV_SUPPORT_UDP_TUNNEL_CSUM_B, caps) ?
+"yes" : "no");
}
static void hns3_dbg_dev_specs(struct hnae3_handle *h)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 850cd3fa..07bdb3d5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -695,7 +695,7 @@ void hns3_enable_vlan_filter(struct net_device *netdev,
bool enable)
}
}
-static int hns3_set_tso(struct sk_buff *skb, u32 *paylen,
+static int hns3_set_tso(struct sk_buff *skb, u32 *paylen_fdop_ol4cs,
u16 *mss, u32 *type_cs_vlan_tso)
{
u32 l4_offset, hdr_len;
@@ -723,7 +723,8 @@ static int hns3_set_tso(struct sk_buff *skb, u32 *paylen,
/* tunnel packet */
if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
SKB_GSO_GRE_CSUM |
-SKB_GSO_UDP_TUNNEL)) {
+SKB_GSO_UDP_TUNNEL |
+SKB_GSO_UDP_TUNNEL_CSUM)) {
/* reset l3 pointers from outer to inner headers */
l3.hdr = skb_inner_network_header(skb);
l4.hdr = skb_inner_transport_header(skb);
@@ -752,9 +753,13 @@ static int hns3_set_tso(struct sk_buff *skb, u32 *paylen,
}
/* find the txbd field values */
- *paylen = skb->len - hdr_len;
+ *paylen_fdop_ol4cs = skb->len - hdr_len;
hns3_set_field(*type_cs_vlan_tso, HNS3_TXD_TSO_B, 1);
+ /* offload outer UDP header checksum */
+ if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)
+ hns3_set_field(*paylen_fdop_ol4cs, HNS3_TXD_OL4CS_B, 1);
+
/* get MSS for TSO */
*mss = skb_shinfo(skb)->gso_size;
@@ -1065,8 +1070,8 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring *ring,
struct sk_buff *skb, struct hns3_desc *desc)
{
u32 ol_type_vlan_len_msec = 0;
+ u32 paylen_ol4cs = skb->len;
u32 type_cs_vlan_tso = 0;
- u32 paylen = skb->len;
u16 mss_hw_csum = 0;
u16 inner_vtag = 0;
u16 out_vtag = 0;
@@ -1125,7 +1130,7 @@ static int hns3_fill_skb_desc(struct hns3_enet_ring *ring,
return ret;
}
- ret = hns3_set_tso(skb, , _hw_csum,
+ ret = hns3_set_tso(skb, _ol4cs, _hw_csum,
_cs_vlan_tso);
[PATCH net-next 5/7] net: hns3: add more info to hns3_dbg_bd_info()
Since TX hardware checksum and RX completion checksum have been
supported now, so add related information in hns3_dbg_bd_info().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 50 +-
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index cb0cc6d..3b27cab 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -179,6 +179,7 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
u32 q_num, value;
dma_addr_t addr;
u16 mss_hw_csum;
+ u32 l234info;
int cnt;
cnt = sscanf(_buf[8], "%u %u", _num, _index);
@@ -213,17 +214,35 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
dev_info(dev, "(TX)vlan_tag: %u\n", le16_to_cpu(tx_desc->tx.vlan_tag));
dev_info(dev, "(TX)send_size: %u\n",
le16_to_cpu(tx_desc->tx.send_size));
- dev_info(dev, "(TX)vlan_tso: %u\n", tx_desc->tx.type_cs_vlan_tso);
- dev_info(dev, "(TX)l2_len: %u\n", tx_desc->tx.l2_len);
- dev_info(dev, "(TX)l3_len: %u\n", tx_desc->tx.l3_len);
- dev_info(dev, "(TX)l4_len: %u\n", tx_desc->tx.l4_len);
+
+ if (mss_hw_csum & BIT(HNS3_TXD_HW_CS_B)) {
+ u32 offset = le32_to_cpu(tx_desc->tx.ol_type_vlan_len_msec);
+ u32 start = le32_to_cpu(tx_desc->tx.type_cs_vlan_tso_len);
+
+ dev_info(dev, "(TX)csum start: %u\n",
+hnae3_get_field(start,
+HNS3_TXD_CSUM_START_M,
+HNS3_TXD_CSUM_START_S));
+ dev_info(dev, "(TX)csum offset: %u\n",
+hnae3_get_field(offset,
+HNS3_TXD_CSUM_OFFSET_M,
+HNS3_TXD_CSUM_OFFSET_S));
+ } else {
+ dev_info(dev, "(TX)vlan_tso: %u\n",
+tx_desc->tx.type_cs_vlan_tso);
+ dev_info(dev, "(TX)l2_len: %u\n", tx_desc->tx.l2_len);
+ dev_info(dev, "(TX)l3_len: %u\n", tx_desc->tx.l3_len);
+ dev_info(dev, "(TX)l4_len: %u\n", tx_desc->tx.l4_len);
+ dev_info(dev, "(TX)vlan_msec: %u\n",
+tx_desc->tx.ol_type_vlan_msec);
+ dev_info(dev, "(TX)ol2_len: %u\n", tx_desc->tx.ol2_len);
+ dev_info(dev, "(TX)ol3_len: %u\n", tx_desc->tx.ol3_len);
+ dev_info(dev, "(TX)ol4_len: %u\n", tx_desc->tx.ol4_len);
+ }
+
dev_info(dev, "(TX)vlan_tag: %u\n",
le16_to_cpu(tx_desc->tx.outer_vlan_tag));
dev_info(dev, "(TX)tv: %u\n", le16_to_cpu(tx_desc->tx.tv));
- dev_info(dev, "(TX)vlan_msec: %u\n", tx_desc->tx.ol_type_vlan_msec);
- dev_info(dev, "(TX)ol2_len: %u\n", tx_desc->tx.ol2_len);
- dev_info(dev, "(TX)ol3_len: %u\n", tx_desc->tx.ol3_len);
- dev_info(dev, "(TX)ol4_len: %u\n", tx_desc->tx.ol4_len);
dev_info(dev, "(TX)paylen_ol4cs: %u\n",
le32_to_cpu(tx_desc->tx.paylen_ol4cs));
dev_info(dev, "(TX)vld_ra_ri: %u\n",
@@ -236,10 +255,21 @@ static int hns3_dbg_bd_info(struct hnae3_handle *h, const
char *cmd_buf)
rx_desc = >desc[rx_index];
addr = le64_to_cpu(rx_desc->addr);
+ l234info = le32_to_cpu(rx_desc->rx.l234_info);
dev_info(dev, "RX Queue Num: %u, BD Index: %u\n", q_num, rx_index);
dev_info(dev, "(RX)addr: %pad\n", );
- dev_info(dev, "(RX)l234_info: %u\n",
-le32_to_cpu(rx_desc->rx.l234_info));
+ dev_info(dev, "(RX)l234_info: %u\n", l234info);
+
+ if (l234info & BIT(HNS3_RXD_L2_CSUM_B)) {
+ __sum16 csum;
+
+ csum = hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_L_M,
+ HNS3_RXD_L2_CSUM_L_S);
+ csum |= hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_H_M,
+ HNS3_RXD_L2_CSUM_H_S) << 8;
+ dev_info(dev, "(RX)csum: %u\n", csum);
+ }
+
dev_info(dev, "(RX)pkt_len: %u\n", le16_to_cpu(rx_desc->rx.pkt_len));
dev_info(dev, "(RX)size: %u\n", le16_to_cpu(rx_desc->rx.size));
dev_info(dev, "(RX)rss_hash: %u\n", le32_to_cpu(rx_desc->rx.rss_hash));
--
2.7.4
[PATCH net-next 3/7] net: hns3: remove unsupported NETIF_F_GSO_UDP_TUNNEL_CSUM
Currently, device V1 and V2 do not support segmentation
offload for UDP based tunnel packet who needs outer UDP
checksum offload, so there is a workaround in the driver
to set the checksum of the outer UDP checksum as zero. This
is not what the user wants, so remove this feature for
device V1 and V2, add support for it later(when the device
has the ability to do that).
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index e022bea..850cd3fa 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -723,17 +723,7 @@ static int hns3_set_tso(struct sk_buff *skb, u32 *paylen,
/* tunnel packet */
if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
SKB_GSO_GRE_CSUM |
-SKB_GSO_UDP_TUNNEL |
-SKB_GSO_UDP_TUNNEL_CSUM)) {
- if ((!(skb_shinfo(skb)->gso_type &
- SKB_GSO_PARTIAL)) &&
- (skb_shinfo(skb)->gso_type &
- SKB_GSO_UDP_TUNNEL_CSUM)) {
- /* Software should clear the udp's checksum
-* field when tso is needed.
-*/
- l4.udp->check = 0;
- }
+SKB_GSO_UDP_TUNNEL)) {
/* reset l3 pointers from outer to inner headers */
l3.hdr = skb_inner_network_header(skb);
l4.hdr = skb_inner_transport_header(skb);
@@ -2357,8 +2347,7 @@ static void hns3_set_default_feature(struct net_device
*netdev)
netdev->hw_enc_features |= NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_GSO |
NETIF_F_GRO | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_SCTP_CRC |
- NETIF_F_TSO_MANGLEID | NETIF_F_FRAGLIST;
+ NETIF_F_SCTP_CRC | NETIF_F_TSO_MANGLEID | NETIF_F_FRAGLIST;
netdev->gso_partial_features |= NETIF_F_GSO_GRE_CSUM;
@@ -2367,23 +2356,20 @@ static void hns3_set_default_feature(struct net_device
*netdev)
NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_GSO |
NETIF_F_GRO | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_SCTP_CRC |
- NETIF_F_FRAGLIST;
+ NETIF_F_SCTP_CRC | NETIF_F_FRAGLIST;
netdev->vlan_features |= NETIF_F_RXCSUM |
NETIF_F_SG | NETIF_F_GSO | NETIF_F_GRO |
NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_SCTP_CRC |
- NETIF_F_FRAGLIST;
+ NETIF_F_SCTP_CRC | NETIF_F_FRAGLIST;
netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_GSO |
NETIF_F_GRO | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_GRE |
NETIF_F_GSO_GRE_CSUM | NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_GSO_UDP_TUNNEL_CSUM | NETIF_F_SCTP_CRC |
- NETIF_F_FRAGLIST;
+ NETIF_F_SCTP_CRC | NETIF_F_FRAGLIST;
if (ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V2) {
netdev->hw_features |= NETIF_F_GRO_HW;
--
2.7.4
[PATCH v2] gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend()
Following Calltrace is found when running echo freeze > /sys/power/state.
[ 272.755506] Unable to handle kernel NULL pointer dereference at virtual
address 0010
[ 272.755585] Call trace:
[ 272.755587] dwapb_gpio_suspend+0x18/0x318
[ 272.755588] pm_generic_suspend+0x2c/0x48
[ 272.755595] acpi_subsys_suspend+0x60/0x70
[ 272.755599] dpm_run_callback.isra.18+0x40/0xe0
[ 272.755601] __device_suspend+0xf4/0x360
The reason is platform_set_drvdata() is deleted, and dwapb_gpio_suspend()
get *gpio by dev_get_drvdata().
Fixes: feeaefd378ca ("gpio: dwapb: Use resource managed GPIO-chip add data
method")
Signed-off-by: Luo Jiaxing
Acked-by: Serge Semin
Reviewed-by: Andy Shevchenko
---
v1->v2:
1. reduce calltrace log
2. delete blank line in tag block
---
---
drivers/gpio/gpio-dwapb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 2a9046c..4275c18 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -724,6 +724,8 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
return err;
}
+ platform_set_drvdata(pdev, gpio);
+
return 0;
}
--
2.7.4
[PATCH] habanalabs/gaudi: handle reset when f/w is in preboot
Currently, if the f/w is in preboot/u-boot they don't perform the new
reset mechanism. Therefore, the driver needs to reset the device.
To prevent reset of PCI_IF, the driver needs to first configure the
reset units.
If the security is enabled, the driver can't configure the reset units.
In that situation, don't reset the card.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudi.c | 60 ++-
1 file changed, 31 insertions(+), 29 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index cd18456fa523..568afe1b6849 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -3829,33 +3829,6 @@ static void gaudi_pre_hw_init(struct hl_device *hdev)
* cleared by the H/W upon H/W reset
*/
WREG32(mmHW_STATE, HL_DEVICE_HW_STATE_DIRTY);
- if (hdev->asic_prop.fw_security_disabled) {
- /* Configure the reset registers. Must be done as early as
-* possible in case we fail during H/W initialization
-*/
- WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST_CFG_H,
- (CFG_RST_H_DMA_MASK |
- CFG_RST_H_MME_MASK |
- CFG_RST_H_SM_MASK |
- CFG_RST_H_TPC_7_MASK));
-
- WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST_CFG_L, CFG_RST_L_TPC_MASK);
-
- WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST_CFG_H,
- (CFG_RST_H_HBM_MASK |
- CFG_RST_H_TPC_7_MASK |
- CFG_RST_H_NIC_MASK |
- CFG_RST_H_SM_MASK |
- CFG_RST_H_DMA_MASK |
- CFG_RST_H_MME_MASK |
- CFG_RST_H_CPU_MASK |
- CFG_RST_H_MMU_MASK));
-
- WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST_CFG_L,
- (CFG_RST_L_IF_MASK |
- CFG_RST_L_PSOC_MASK |
- CFG_RST_L_TPC_MASK));
- }
}
static int gaudi_hw_init(struct hl_device *hdev)
@@ -3946,7 +3919,8 @@ static void gaudi_hw_fini(struct hl_device *hdev, bool
hard_reset)
/* Set device to handle FLR by H/W as we will put the device CPU to
* halt mode
*/
- if (!hdev->asic_prop.hard_reset_done_by_fw)
+ if (hdev->asic_prop.fw_security_disabled &&
+ !hdev->asic_prop.hard_reset_done_by_fw)
WREG32(mmPCIE_AUX_FLR_CTRL, (PCIE_AUX_FLR_CTRL_HW_CTRL_MASK |
PCIE_AUX_FLR_CTRL_INT_MASK_MASK));
@@ -3957,7 +3931,35 @@ static void gaudi_hw_fini(struct hl_device *hdev, bool
hard_reset)
WREG32(mmGIC_DISTRIBUTOR__5_GICD_SETSPI_NSR, GAUDI_EVENT_HALT_MACHINE);
- if (!hdev->asic_prop.hard_reset_done_by_fw) {
+ if (hdev->asic_prop.fw_security_disabled &&
+ !hdev->asic_prop.hard_reset_done_by_fw) {
+
+ /* Configure the reset registers. Must be done as early as
+* possible in case we fail during H/W initialization
+*/
+ WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST_CFG_H,
+ (CFG_RST_H_DMA_MASK |
+ CFG_RST_H_MME_MASK |
+ CFG_RST_H_SM_MASK |
+ CFG_RST_H_TPC_7_MASK));
+
+ WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST_CFG_L, CFG_RST_L_TPC_MASK);
+
+ WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST_CFG_H,
+ (CFG_RST_H_HBM_MASK |
+ CFG_RST_H_TPC_7_MASK |
+ CFG_RST_H_NIC_MASK |
+ CFG_RST_H_SM_MASK |
+ CFG_RST_H_DMA_MASK |
+ CFG_RST_H_MME_MASK |
+ CFG_RST_H_CPU_MASK |
+ CFG_RST_H_MMU_MASK));
+
+ WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST_CFG_L,
+ (CFG_RST_L_IF_MASK |
+ CFG_RST_L_PSOC_MASK |
+ CFG_RST_L_TPC_MASK));
+
msleep(cpu_timeout_ms);
/* Tell ASIC not to re-initialize PCIe */
--
2.17.1
Re: [PATCH v4 01/16] dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains controller
Hi Weiyi, On 27/11/20 3:24, Weiyi Lu wrote: > On Fri, 2020-10-30 at 12:36 +0100, Enric Balletbo i Serra wrote: >> The System Control Processor System (SCPSYS) has several power management >> related tasks in the system. Add the bindings to define the power >> domains for the SCPSYS power controller. >> >> Co-developed-by: Matthias Brugger >> Signed-off-by: Matthias Brugger >> Signed-off-by: Enric Balletbo i Serra >> Reviewed-by: Rob Herring >> --- >> >> Changes in v4: >> - Fix indentation warnings reported by yamllint >> >> Changes in v3: >> - Use hex for unit-addresses. >> - Define child nodes for nested power domains even are duplicated, but >> more clear than adding a regex scaped to be a valid URI. >> >> Changes in v2: >> - Use generic node names (power-domain). >> - Define valid values for common properties like #power-domain-cells. >> >> .../power/mediatek,power-controller.yaml | 289 ++ >> 1 file changed, 289 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> new file mode 100644 >> index ..73b8988bd063 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml >> @@ -0,0 +1,289 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/power/mediatek,power-controller.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Mediatek Power Domains Controller >> + >> +maintainers: >> + - Weiyi Lu >> + - Matthias Brugger >> + >> +description: | >> + Mediatek processors include support for multiple power domains which can >> be >> + powered up/down by software based on different application scenes to save >> power. >> + >> + IP cores belonging to a power domain should contain a 'power-domains' >> + property that is a phandle for SCPSYS node representing the domain. >> + >> +properties: >> + $nodename: >> +const: power-controller >> + >> + compatible: >> +enum: >> + - mediatek,mt8173-power-controller >> + >> + '#power-domain-cells': >> +const: 1 >> + >> + '#address-cells': >> +const: 1 >> + >> + '#size-cells': >> +const: 0 >> + >> +patternProperties: >> + "^power-domain@[0-9a-f]+$": >> +type: object >> +description: | >> + Represents the power domains within the power controller node as >> documented >> + in Documentation/devicetree/bindings/power/power-domain.yaml. >> + >> +properties: >> + >> + '#power-domain-cells': >> +description: >> + Must be 0 for nodes representing a single PM domain and 1 for >> nodes >> + providing multiple PM domains. >> + >> + '#address-cells': >> +const: 1 >> + >> + '#size-cells': >> +const: 0 >> + >> + reg: >> +description: | >> + Power domain index. Valid values are defined in: >> + "include/dt-bindings/power/mt8173-power.h" - for MT8173 type >> power domain. >> +maxItems: 1 >> + >> + clocks: >> +description: | >> + A number of phandles to clocks that need to be enabled during >> domain >> + power-up sequencing. >> + >> + clock-names: >> +description: | >> + List of names of clocks, in order to match the power-up sequencing >> + for each power domain we need to group the clocks by name. BASIC >> + clocks need to be enabled before enabling the corresponding power >> + domain, and should not have a '-' in their name (i.e mm, mfg, >> venc). >> + SUSBYS clocks need to be enabled before releasing the bus >> protection, >> + and should contain a '-' in their name (i.e mm-0, isp-0, cam-0). >> + >> + In order to follow properly the power-up sequencing, the clocks >> must >> + be specified by order, adding first the BASIC clocks followed by >> the >> + SUSBSYS clocks. >> + >> + mediatek,infracfg: >> +$ref: /schemas/types.yaml#definitions/phandle >> +description: phandle to the device containing the INFRACFG register >> range. >> + >> + mediatek,smi: >> +$ref: /schemas/types.yaml#definitions/phandle >> +description: phandle to the device containing the SMI register >> range. >> + >> +patternProperties: >> + "^power-domain@[0-9a-f]+$": >> +type: object >> +description: | >> + Represents a power domain child within a power domain parent node. >> + >> +properties: >> + >> + '#power-domain-cells': >> +description: >> + Must be 0 for nodes representing a single PM domain and 1 for >> nodes >> + providing multiple PM domains. >> + >> + '#address-cells': >> +
Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
On Fri, 27 Nov 2020, Pkshih wrote: > On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote: > > On Fri, 27 Nov 2020, Pkshih wrote: > > > > > > > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'. > > > > > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote: > > > > Also strip out other duplicates from driver specific headers. > > > > > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter > > > > uses some defines from the former. It avoids issues like: > > > > > > > > from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5: > > > > drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: > > > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean > > > > ‘RTK_MAX_RX_DESC_NUM’? > > > > 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM); > > > > | ^~~~ > > > > > > > > Fixes the following W=1 kernel build warning(s): > > > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous > > > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes] > > > > 1488 | int rtw_pci_probe(struct pci_dev *pdev, > > > > | ^ > > > > drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous > > > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes] > > > > 1568 | void rtw_pci_remove(struct pci_dev *pdev) > > > > | ^~ > > > > drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous > > > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes] > > > > 1590 | void rtw_pci_shutdown(struct pci_dev *pdev) > > > > | ^~~~ > > > > > > > > Cc: Yan-Hsuan Chuang > > > > Cc: Kalle Valo > > > > Cc: "David S. Miller" > > > > Cc: Jakub Kicinski > > > > Cc: linux-wirel...@vger.kernel.org > > > > Cc: net...@vger.kernel.org > > > > Signed-off-by: Lee Jones > > > > --- > > > > drivers/net/wireless/realtek/rtw88/pci.h | 8 > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 + > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 + > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 + > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 + > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 > > > > 9 files changed, 12 insertions(+), 16 deletions(-) > > > > > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h > > > > b/drivers/net/wireless/realtek/rtw88/pci.h > > > > index ca17aa9cf7dc7..cda56919a5f0f 100644 > > > > --- a/drivers/net/wireless/realtek/rtw88/pci.h > > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h > > > > @@ -5,6 +5,8 @@ > > > > #ifndef __RTK_PCI_H_ > > > > #define __RTK_PCI_H_ > > > > > > > > +#include "main.h" > > > > + > > > > > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c. > > > > You mean instead of in pci.h? > > > > Surely that's a hack. > > > > I mean don't include main.h in pci.h, but include both of them in each > of rtw8e.c. > > +#include "main.h" > +#include "pci.h" Yes, that's what I thought you meant. I think that's a hack. Source files shouldn't rely on the ordering of include files to resolve dependencies. In fact, a lot of subsystems require includes to be in alphabetical order. If a source or header file references a resource from a specific header file (for instance here pci.h uses defines from main.h) then it should explicitly include it. Can you tell me the technical reason as to why these drivers are handled differently please? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3] s390/pci: fix CPU address in MSI for directed IRQ
On Thu, 26 Nov 2020 18:00:37 +0100
Alexander Gordeev wrote:
> The directed MSIs are delivered to CPUs whose address is
> written to the MSI message data. The current code assumes
> that a CPU logical number (as it is seen by the kernel)
> is also that CPU address.
>
> The above assumption is not correct, as the CPU address
> is rather the value returned by STAP instruction. That
> value does not necessarily match the kernel logical CPU
> number.
>
> Fixes: e979ce7bced2 ("s390/pci: provide support for CPU directed interrupts")
> Signed-off-by: Alexander Gordeev
> ---
> arch/s390/pci/pci_irq.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/s390/pci/pci_irq.c b/arch/s390/pci/pci_irq.c
> index 743f257cf2cb..75217fb63d7b 100644
> --- a/arch/s390/pci/pci_irq.c
> +++ b/arch/s390/pci/pci_irq.c
> @@ -103,9 +103,10 @@ static int zpci_set_irq_affinity(struct irq_data *data,
> const struct cpumask *de
> {
> struct msi_desc *entry = irq_get_msi_desc(data->irq);
> struct msi_msg msg = entry->msg;
> + int cpu_addr = smp_cpu_get_cpu_address(cpumask_first(dest));
>
> msg.address_lo &= 0xffff;
> - msg.address_lo |= (cpumask_first(dest) << 8);
> + msg.address_lo |= (cpu_addr << 8);
> pci_write_msi_msg(data->irq, );
>
> return IRQ_SET_MASK_OK;
> @@ -238,6 +239,7 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec,
> int type)
> unsigned long bit;
> struct msi_desc *msi;
> struct msi_msg msg;
> + int cpu_addr;
> int rc, irq;
>
> zdev->aisb = -1UL;
> @@ -287,9 +289,15 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec,
> int type)
>handle_percpu_irq);
> msg.data = hwirq - bit;
> if (irq_delivery == DIRECTED) {
> + if (msi->affinity)
> + cpu = cpumask_first(>affinity->mask);
> + else
> + cpu = 0;
> + cpu_addr = smp_cpu_get_cpu_address(cpu);
> +
I thin style wise, I would prefer keeping the ternary operator instead
of rewriting it as an if-then-else, i.e.:
cpu_addr = smp_cpu_get_cpu_address(msi->affinity ?
cpumask_first(>affinity->mask) : 0);
but either way:
Reviewed-by: Halil Pasic
> msg.address_lo = zdev->msi_addr & 0xffff;
> - msg.address_lo |= msi->affinity ?
> - (cpumask_first(>affinity->mask) << 8) : 0;
> + msg.address_lo |= (cpu_addr << 8);
> +
> for_each_possible_cpu(cpu) {
> airq_iv_set_data(zpci_ibv[cpu], hwirq, irq);
> }
Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.
On Sun, Nov 22, 2020 at 2:56 AM Tetsuo Handa
wrote:
>
> On 2020/11/20 18:27, Dmitry Vyukov wrote:
> > Peter, so far it looks like just a very large, but normal graph to me.
> > The cheapest from an engineering point of view solution would be just
> > to increase the constants. I assume a 2x increase should buy us lots
> > of time to overflow.
> > I can think of more elaborate solutions, e.g. using bitmasks to
> > represent hot leaf and top-level locks. But it will both increase the
> > resulting code complexity (no uniform representation anymore, all code
> > will need to deal with different representations) and require some
> > time investments (that I can't justify for me at least as compared to
> > just throwing a bit more machine memory at it). And in the end it
> > won't really reduce the size of the graph.
> > What do you think?
> >
>
> Yes, I think it is a normal graph; simply syzkaller kernels tend to record
> a few times more dependencies than my idle kernel (shown bottom).
>
> Peter, you guessed that the culprit is sysfs at
> https://lkml.kernel.org/r/20200916115057.go2...@hirez.programming.kicks-ass.net
> , but
> syzbot reported at
> https://syzkaller.appspot.com/text?tag=MachineInfo=99b8f2b092d9714f
> that "BUG: MAX_LOCKDEP_ENTRIES too low!" can occur on a VM with only 2 CPUs.
> Is your guess catching the culprit?
>
> We could improve a few locks, but as a whole we won't be able to afford
> keeping
> sum of individual dependencies under current threshold. Therefore, allow
> lockdep to
> tune the capacity and allow syzkaller to dump when reaching the capacity will
> be
> the way to go.
>
>
>
> # cat /proc/lockdep_stats
> lock-classes: 1236 [max: 8192]
> direct dependencies: 9610 [max: 32768]
> indirect dependencies: 40401
> all direct dependencies:174635
> dependency chains: 11398 [max: 65536]
> dependency chain hlocks used:42830 [max: 327680]
> dependency chain hlocks lost:0
> in-hardirq chains: 61
> in-softirq chains: 414
> in-process chains: 10923
> stack-trace entries: 93041 [max: 524288]
> number of stack traces: 4997
> number of stack hash chains: 4292
> combined max dependencies: 281074520
> hardirq-safe locks: 50
> hardirq-unsafe locks: 805
> softirq-safe locks:146
> softirq-unsafe locks: 722
> irq-safe locks:155
> irq-unsafe locks: 805
> hardirq-read-safe locks: 2
> hardirq-read-unsafe locks: 129
> softirq-read-safe locks:11
> softirq-read-unsafe locks: 123
> irq-read-safe locks:11
> irq-read-unsafe locks: 129
> uncategorized locks: 224
> unused locks:0
> max locking depth: 15
> max bfs queue depth: 215
> chain lookup misses: 11664
> chain lookup hits:37393935
> cyclic checks: 11053
> redundant checks:0
> redundant links: 0
> find-mask forwards checks:1588
> find-mask backwards checks: 1779
> hardirq on events:17502380
> hardirq off events: 17502376
> redundant hardirq ons: 0
> redundant hardirq offs: 0
> softirq on events: 90845
> softirq off events: 90845
> redundant softirq ons: 0
> redundant softirq offs: 0
> debug_locks: 1
>
> zapped classes: 0
> zapped lock chains: 0
> large chain blocks: 1
> # awk ' { if ($2 == "OPS:") print $5" "$9 } ' /proc/lockdep | sort -rV | head
> -n 30
> 423 (wq_completion)events
> 405 (wq_completion)events_unbound
> 393 >f_pos_lock
> 355 >lock
> 349 sb_writers#3
> 342 sb_writers#6
> 338 >mutex
> 330 (work_completion)(>work)
> 330 pernet_ops_rwsem
> 289 epmutex
> 288 >mtx
> 281 tty_mutex
> 280 >legacy_mutex
> 273 >legacy_mutex/1
> 269 >ldisc_sem
> 268 (wq_completion)ipv6_addrconf
> 266 (work_completion)(&(>dad_work)->work)
> 266 (linkwatch_work).work
> 266 (addr_chk_work).work
> 266 >atomic_read_lock
> 265 (work_completion)(>work)
> 265 rtnl_mutex
> 263 >atomic_write_lock
> 262 >lock
> 261 >termios_rwsem
> 242 >buf.lock/1
> 242 kn->active#40
> 241 _tty->termios_rwsem/1
> 240 registration_lock
> 239 >output_lock
> # awk ' { if ($2 == "OPS:") print $7" "$9 } ' /proc/lockdep | sort -rV | head
> -n 30
> 642 pool_lock
> 641 _hash[i].lock
> 582 tk_core.seq.seqcount
> 561 hrtimer_bases.lock
> 560 _rq->rt_runtime_lock
> 559 _b->rt_runtime_lock
> 559 >lock
> 559
[PATCH v2] Asoc: qcom: Fix plaback recover problem in suspend resume
To support playback continuation after hard suspend(bypass powerd)
and resume:
Prepare device in platform trigger callback.
Make I2s and DMA control registers as non volatile.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
Changes Since v1:
-- Subject lines changed
sound/soc/qcom/lpass-cpu.c | 8 ++--
sound/soc/qcom/lpass-platform.c | 5 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index af684fd..c99be03 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -454,20 +454,16 @@ static bool lpass_cpu_regmap_volatile(struct device *dev,
unsigned int reg)
struct lpass_variant *v = drvdata->variant;
int i;
- for (i = 0; i < v->i2s_ports; ++i)
- if (reg == LPAIF_I2SCTL_REG(v, i))
- return true;
for (i = 0; i < v->irq_ports; ++i)
if (reg == LPAIF_IRQSTAT_REG(v, i))
return true;
for (i = 0; i < v->rdma_channels; ++i)
- if (reg == LPAIF_RDMACURR_REG(v, i) || reg ==
LPAIF_RDMACTL_REG(v, i))
+ if (reg == LPAIF_RDMACURR_REG(v, i))
return true;
for (i = 0; i < v->wrdma_channels; ++i)
- if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start) ||
- reg == LPAIF_WRDMACTL_REG(v, i +
v->wrdma_channel_start))
+ if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start))
return true;
return false;
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 80b09de..2b0a7c1 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -481,8 +481,9 @@ static int lpass_platform_pcmops_trigger(struct
snd_soc_component *component,
return -ENOTRECOVERABLE;
}
switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
+ lpass_platform_pcmops_prepare(component, substream);
+ case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
ret = regmap_fields_write(dmactl->enable, id,
LPAIF_DMACTL_ENABLE_ON);
@@ -592,7 +593,7 @@ static int lpass_platform_pcmops_trigger(struct
snd_soc_component *component,
break;
}
- return 0;
+ return ret;
}
static snd_pcm_uframes_t lpass_platform_pcmops_pointer(
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC 1/3] mm/hotplug: Pre-validate the address range with platform
>>
>> "arch_get_mappable_range(void)" (or similar) ?
>
> The current name seems bit better (I guess). Because we are asking for
> max addressable range with or without the linear mapping.
>
>>
>> AFAIKs, both implementations (arm64/s390x) simply do the exact same
>> thing as memhp_get_pluggable_range() for !need_mapping.
>
> That is for now. Even the range without requiring linear mapping might not
> be the same (like now) for every platform as some might have constraints.
> So asking the platform ranges with or without linear mapping seems to be
> better and could accommodate special cases going forward. Anyways, there
> is an always an "all allowing" fallback option nonetheless.
Let's keep it simple as long as we don't have a real scenario where this
would apply.
[...]
>
>>
>>> + return true;
>>> +
>>> + WARN(1, "Hotplug memory [%#llx-%#llx] exceeds maximum addressable range
>>> [%#llx-%#llx]\n",
>>> + start, end, memhp_range.start, memhp_range.end);
>>
>> pr_warn() (or even pr_warn_once())
>>
>> while we're at it. No reason to eventually crash a system :)
>
> Didn't quite get it. How could this crash the system ?
With panic_on_warn, which some distributions started to enable.
[...]
>>> /*
>>> * Validate altmap is within bounds of the total request
>>> @@ -1109,6 +1089,9 @@ int __ref __add_memory(int nid, u64 start, u64 size,
>>> mhp_t mhp_flags)
>>> struct resource *res;
>>> int ret;
>>>
>>> + if (!memhp_range_allowed(start, size, 1))
>>> + return -ERANGE;
>>
>> We used to return -E2BIG, no? Maybe better keep that.
>
> ERANGE seems to be better as the range can overrun on either side.
Did you check all callers that they can handle it? Should mention that
in the patch description then.
>
>>
>>> +
>>> res = register_memory_resource(start, size, "System RAM");
>>> if (IS_ERR(res))
>>> return PTR_ERR(res);
>>> @@ -1123,6 +1106,9 @@ int add_memory(int nid, u64 start, u64 size, mhp_t
>>> mhp_flags)
>>> {
>>> int rc;
>>>
>>> + if (!memhp_range_allowed(start, size, 1))
>>> + return -ERANGE;
>>> +
>>> lock_device_hotplug();
>>> rc = __add_memory(nid, start, size, mhp_flags);
>>> unlock_device_hotplug();
>>> @@ -1163,6 +1149,9 @@ int add_memory_driver_managed(int nid, u64 start, u64
>>> size,
>>> resource_name[strlen(resource_name) - 1] != ')')
>>> return -EINVAL;
>>>
>>> + if (!memhp_range_allowed(start, size, 0))
>>> + return -ERANGE;
>>> +
>>> lock_device_hotplug();
>>
>> For all 3 cases, doing a single check in register_memory_resource() is
>> sufficient.
>
> Will replace with a single check in register_memory_resource(). But does
> add_memory_driver_managed() always require linear mapping ? The proposed
> check here did not ask for linear mapping in add_memory_driver_managed().
Yes, in that regard, it behaves just like add_memory().
--
Thanks,
David / dhildenb
[PATCH] f2fs: introduce a new per-sb directory in sysfs
Add a new directory 'stat' in path of /sys/fs/f2fs//, later
we can add new readonly stat sysfs file into this directory, it will
make directory less mess.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h | 5 +++-
fs/f2fs/sysfs.c | 69 +
2 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0d38f2135016..a20059dece46 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1510,9 +1510,12 @@ struct f2fs_sb_info {
unsigned int node_io_flag;
/* For sysfs suppport */
- struct kobject s_kobj;
+ struct kobject s_kobj; /* /sys/fs/f2fs/ */
struct completion s_kobj_unregister;
+ struct kobject s_stat_kobj; /* /sys/fs/f2fs//stat
*/
+ struct completion s_stat_kobj_unregister;
+
/* For shrinker support */
struct list_head s_list;
int s_ndevs;/* number of devices */
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index ec77ccfea923..8c63a6e61dfd 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -708,6 +708,11 @@ static struct attribute *f2fs_feat_attrs[] = {
};
ATTRIBUTE_GROUPS(f2fs_feat);
+static struct attribute *f2fs_stat_attrs[] = {
+ NULL,
+};
+ATTRIBUTE_GROUPS(f2fs_stat);
+
static const struct sysfs_ops f2fs_attr_ops = {
.show = f2fs_attr_show,
.store = f2fs_attr_store,
@@ -736,6 +741,44 @@ static struct kobject f2fs_feat = {
.kset = _kset,
};
+static ssize_t f2fs_stat_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ struct f2fs_attr *a = container_of(attr, struct f2fs_attr, attr);
+
+ return a->show ? a->show(a, sbi, buf) : 0;
+}
+
+static ssize_t f2fs_stat_attr_store(struct kobject *kobj, struct attribute
*attr,
+ const char *buf, size_t len)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ struct f2fs_attr *a = container_of(attr, struct f2fs_attr, attr);
+
+ return a->store ? a->store(a, sbi, buf, len) : 0;
+}
+
+static void f2fs_stat_kobj_release(struct kobject *kobj)
+{
+ struct f2fs_sb_info *sbi = container_of(kobj, struct f2fs_sb_info,
+ s_stat_kobj);
+ complete(>s_stat_kobj_unregister);
+}
+
+static const struct sysfs_ops f2fs_stat_attr_ops = {
+ .show = f2fs_stat_attr_show,
+ .store = f2fs_stat_attr_store,
+};
+
+static struct kobj_type f2fs_stat_ktype = {
+ .default_groups = f2fs_stat_groups,
+ .sysfs_ops = _stat_attr_ops,
+ .release= f2fs_stat_kobj_release,
+};
+
static int __maybe_unused segment_info_seq_show(struct seq_file *seq,
void *offset)
{
@@ -942,11 +985,15 @@ int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
init_completion(>s_kobj_unregister);
err = kobject_init_and_add(>s_kobj, _sb_ktype, NULL,
"%s", sb->s_id);
- if (err) {
- kobject_put(>s_kobj);
- wait_for_completion(>s_kobj_unregister);
- return err;
- }
+ if (err)
+ goto put_sb_kobj;
+
+ sbi->s_stat_kobj.kset = _kset;
+ init_completion(>s_stat_kobj_unregister);
+ err = kobject_init_and_add(>s_stat_kobj, _stat_ktype,
+ >s_kobj, "stat");
+ if (err)
+ goto put_stat_kobj;
if (f2fs_proc_root)
sbi->s_proc = proc_mkdir(sb->s_id, f2fs_proc_root);
@@ -962,6 +1009,13 @@ int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
victim_bits_seq_show, sb);
}
return 0;
+put_stat_kobj:
+ kobject_put(>s_stat_kobj);
+ wait_for_completion(>s_stat_kobj_unregister);
+put_sb_kobj:
+ kobject_put(>s_kobj);
+ wait_for_completion(>s_kobj_unregister);
+ return err;
}
void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
@@ -973,6 +1027,11 @@ void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
remove_proc_entry("victim_bits", sbi->s_proc);
remove_proc_entry(sbi->sb->s_id, f2fs_proc_root);
}
+
+ kobject_del(>s_stat_kobj);
+ kobject_put(>s_stat_kobj);
+ wait_for_completion(>s_stat_kobj_unregister);
+
kobject_del(>s_kobj);
kobject_put(>s_kobj);
wait_for_completion(>s_kobj_unregister);
--
2.26.2
linux-next: Tree for Nov 27
Hi all, Changes since 20201126: The dma-mapping tree gained a build failure for which I applied a patch. The tip tree gained a build failure for which I applied a patch. The regmap tree gained a build failure for which I reverted a commit. The akpm-current tree gained conflicts against the risc-v and tip trees. Non-merge commits (relative to Linus' tree): 8258 7914 files changed, 630057 insertions(+), 133018 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (85a2c56cb445 Merge tag 'pm-5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fixes/fixes (418baf2c28f3 Linux 5.10-rc5) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (f737561c7096 ARC: stack unwinding: reorganize how initial register state setup) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (ff1712f953e2 arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect()) Merging arm-soc-fixes/arm/fixes (06ceddef30a5 Merge tag 'tegra-for-5.10-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (b6b79dd53082 powerpc/64s: Fix allnoconfig build since uaccess flush) Merging s390-fixes/fixes (1179f170b6f0 s390: fix fpu restore in entry.S) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (cbf3d60329c4 ch_ktls: lock is not freed) Merging bpf/master (9a44bc9449cf bpf: Add MAINTAINERS entry for BPF LSM) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (c0700dfa2cae netfilter: nf_tables: avoid false-postive lockdep splat) Merging ipvs/master (c0700dfa2cae netfilter: nf_tables: avoid false-postive lockdep splat) Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in case of assert during CSA) Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()) Merging rdma-fixes/for-rc (17475e104dcb RDMA/hns: Bugfix for memory window mtpt configuration) Merging sound-current/for-linus (eeacd80fcb29 ALSA: hda/realtek: Enable headset of ASUS UX482EG & B9400CEA with ALC294) Merging sound-asoc-fixes/for-linus (23f57ae2bfe4 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (e6e9354b5830 regmap: Remove duplicate `type` field from regmap `regcache_sync` trace event) Merging regulator-fixes/for-linus (34c5aa2666db regulator: Kconfig: Fix REGULATOR_QCOM_RPMH dependencies to avoid build error) Merging spi-fixes/for-linus (5ac359ce36d3 Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (cce14622a703 PCI: Add function 1 DMA alias quirk for Marvell 9215
[PATCH] clk: rockchip: Remove redundant null check before clk_prepare_enable
Because clk_prepare_enable() already checked NULL clock parameter,
so the additional check is unnecessary, just remove it.
Signed-off-by: Xu Wang
---
drivers/clk/rockchip/clk.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index b443169dd408..336481bc6cc7 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -603,8 +603,7 @@ void rockchip_clk_protect_critical(const char *const
clocks[],
for (i = 0; i < nclocks; i++) {
struct clk *clk = __clk_lookup(clocks[i]);
- if (clk)
- clk_prepare_enable(clk);
+ clk_prepare_enable(clk);
}
}
EXPORT_SYMBOL_GPL(rockchip_clk_protect_critical);
--
2.17.1
Re: [RFC PATCH 2/2] power: supply: add sw-gauge for SOC estimation and CC correction
On Thu, 2020-11-26 at 12:13 +0200, Matti Vaittinen wrote:
> Add generic 'sw gauge' helper for performing iterative SOC estimation
> and coulomb counter correction for devices with a (drifting) coulomb
> counter. This should allow few charger/fuel-gauge drivers to use
> generic
> loop instead of implementing their own.
>
> Charger/fuel-gauge drivers can register 'sw-gauge' which does
> periodically
> poll the driver and:
> - get battery state
> - adjust coulomb counter value (to fix drifting caused for example
> by ADC
>offset) if:
> - Battery is relaxed and OCV<=>SOC table is given
> - Battery is full charged
> - get battery age (cycles) from driver
> - get battery temperature
> - do battery capacity correction
> - by battery temperature
> - by battery age
> - by computed Vbat/OCV difference at low-battery condition if
>low-limit is set and OCV table given
> - by IC specific low-battery correction if provided
> - compute current State Of Charge (SOC)
> - do periodical calibration if IC supports that. (Many ICs do
> calibration
>of CC by shorting the ADC pins and getting the offset).
>
> The SW gauge provides the last computed SOC as
> POWER_SUPPLY_PROP_CAPACITY
> to power_supply_class when requested.
>
> Things that should/could be added but are missing from this commit:
> - Support starting calibration in HW when entering to suspend. This
>is useful for ICs supporting delayed calibration to mitigate CC
> error
>during suspend - and to make periodical wake-up less critical.
> - provide the user-space a consistent interface for getting/setting
> the
>battery-cycle information for ICs which can't store the battery
> aging
>information (like how many times battery has been charged to full)
>over reset. Should POWER_SUPPLY_PROP_CYCLE_COUNT be used?
> - periodical wake-up for performing SOC estimation computation (RTC
>integration)
>
> Signed-off-by: Matti Vaittinen
> ---
>
> Please do not spend hours with full formal review. The code here is
> provided to explain what I thought of working with and needs proper
> testing prior full review can be beneficial. I hope this still helps
> to explain what I have on mind. If this is seen worth the further
> work - then I will rework and test this + send a proper code for
> review. This one was only compile tested. I just hope to get opinion
> whether I should put further work on this or not :)
>
> drivers/power/supply/Kconfig| 8 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/power_supply_swgauge.c | 808
>
> include/linux/power/sw_gauge.h | 203 +
> include/linux/power_supply.h| 6 +
> 5 files changed, 1026 insertions(+)
> create mode 100644 drivers/power/supply/power_supply_swgauge.c
> create mode 100644 include/linux/power/sw_gauge.h
>
// Snip
> +
> +static int adjust_cc_full(struct sw_gauge *sw)
> +{
> + int ret, full_uah;
> +
> + if (sw->ops.get_uah_cc_full)
>
> + if (sw->ops.get_cycle) {+ ret = sw-
> >ops.get_uah_cc_full(sw, _uah);
I started converting the ROHM BD71827/BD71828/BD71815 drivers to this
format to get more concrete version... And I noticed I had completely
brainfarted here. Sorry! The idea is of course to set the new CC
value based on information that battery was fully charged. Eg, idea is
to allow driver to not implement get_uah_cc_full but
get_uah_cc_from_full() - to retrieve CC lost since charger informed
battery is full.
> + else
> + ret = sw->ops.get_uah_cc(sw, _uah);
This one is nonsense too. If no get_uah_cc_from_full() is implemented
we assume battery is full right now. What we do next is substract the
uAh's lost since full from designed (and age/temp corrected? TBD)
battery capacity and set this value to CC.
I was after something like:
full_uah = sw->designed_cap - uah_from_full;
As I said - this RFC is not for final review but this particular error
probably obfuscated the logic completely :| Sorry!
> + /*
> + * ROHM algorithm adjusts CC here based on designed capacity
> and not
> + * based on age/temperature corrected capacity.
> + *
> + * Let's try to use age-compensated capacity unlike original
> algorithm.
> + */
> + ret = age_correct_cap(sw, _uah);
> + if (ret) {
> + pr_err("Age correction of battery failed\n");
> + return ret;
> + }
> + return sw->ops.update_cc_uah(sw, full_uah);
> +}
> +/*
> + * Some charger ICs keep count of battery charge systems but can
> only store
> + * one or few cycles. They may need to clear the cycle counter and
> update
> + * counter in SW. This function fetches the counter from HW and
> allows HW to
> + * clear IC counter if needed.
> + *
> + * TODO: Add sysfs to export counter value to user-space and to
> allow
> + * user-space to set it after reset.
And while I was anyways writing this reply
Re: [PATCH v6 3/5] mtd: spi-nor: intel: remove global protection flag
On 11/26/20 10:26 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> For the Atmel and SST parts this flag was already moved to individual
> flash parts because it is considered bad esp. because newer flash chips
> will automatically inherit the "has locking" support. While this won't
> likely be the case for the Intel parts, we do it for consistency
> reasons.
>
> Signed-off-by: Michael Walle
Reviewed-by: Tudor Ambarus
> ---
> changes since v5
> - new patch
>
> drivers/mtd/spi-nor/intel.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/intel.c b/drivers/mtd/spi-nor/intel.c
> index d8196f101368..6c31bef3fc60 100644
> --- a/drivers/mtd/spi-nor/intel.c
> +++ b/drivers/mtd/spi-nor/intel.c
> @@ -10,23 +10,13 @@
>
> static const struct flash_info intel_parts[] = {
> /* Intel/Numonyx -- xxxs33b */
> - { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
> - { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, 0) },
> - { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, 0) },
> -};
> -
> -static void intel_default_init(struct spi_nor *nor)
> -{
> - nor->flags |= SNOR_F_HAS_LOCK;
> -}
> -
> -static const struct spi_nor_fixups intel_fixups = {
> - .default_init = intel_default_init,
> + { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, SPI_NOR_HAS_LOCK) },
> + { "320s33b", INFO(0x898912, 0, 64 * 1024, 64, SPI_NOR_HAS_LOCK) },
> + { "640s33b", INFO(0x898913, 0, 64 * 1024, 128, SPI_NOR_HAS_LOCK) },
> };
>
> const struct spi_nor_manufacturer spi_nor_intel = {
> .name = "intel",
> .parts = intel_parts,
> .nparts = ARRAY_SIZE(intel_parts),
> - .fixups = _fixups,
> };
> --
> 2.20.1
>
Re: [RESEND PATCH v2] dt-bindings: net: correct interrupt flags in examples
On 10/26/20 4:36 PM, Krzysztof Kozlowski wrote: > GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. > These are simple defines so they could be used in DTS but they will not > have the same meaning: > 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE > 2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING > > Correct the interrupt flags, assuming the author of the code wanted same > logical behavior behind the name "ACTIVE_xxx", this is: > ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW > ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH > > Signed-off-by: Krzysztof Kozlowski > Acked-by: Rob Herring > Acked-by: Marc Kleine-Budde # for tcan4x5x.txt Jakub, can you queue this patch for net/master? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
[PATCH] drm/armada: Remove redundant null check before clk_disable_unprepare
Because clk_disable_unprepare() already checked NULL clock parameter,
so the additional check is unnecessary, just remove it.
Signed-off-by: Xu Wang
---
drivers/gpu/drm/armada/armada_510.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_510.c
b/drivers/gpu/drm/armada/armada_510.c
index 93d5c0a2d49a..05fe97900b13 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -132,10 +132,8 @@ static int armada510_crtc_compute_clock(struct armada_crtc
*dcrtc,
static void armada510_crtc_disable(struct armada_crtc *dcrtc)
{
- if (dcrtc->clk) {
- clk_disable_unprepare(dcrtc->clk);
- dcrtc->clk = NULL;
- }
+ clk_disable_unprepare(dcrtc->clk);
+ dcrtc->clk = NULL;
}
static void armada510_crtc_enable(struct armada_crtc *dcrtc,
--
2.17.1
Re: [PATCH 2/2] mm/debug_vm_pgtable/basic: Iterate over entire protection_map[]
On 27/11/2020 05:06, Anshuman Khandual wrote:
Currently the basic tests just validate various page table transformations
after starting with vm_get_page_prot(VM_READ|VM_WRITE|VM_EXEC) protection.
Instead scan over the entire protection_map[] for better coverage. It also
makes sure that all these basic page table tranformations checks hold true
irrespective of the starting protection value for the page table entry.
There is also a slight change in the debug print format for basic tests to
capture the protection value it is being tested with. The modified output
looks something like
[pte_basic_tests ]: Validating PTE basic ()
[pte_basic_tests ]: Validating PTE basic (read)
[pte_basic_tests ]: Validating PTE basic (write)
[pte_basic_tests ]: Validating PTE basic (read|write)
[pte_basic_tests ]: Validating PTE basic (exec)
[pte_basic_tests ]: Validating PTE basic (read|exec)
[pte_basic_tests ]: Validating PTE basic (write|exec)
[pte_basic_tests ]: Validating PTE basic (read|write|exec)
[pte_basic_tests ]: Validating PTE basic (shared)
[pte_basic_tests ]: Validating PTE basic (read|shared)
[pte_basic_tests ]: Validating PTE basic (write|shared)
[pte_basic_tests ]: Validating PTE basic (read|write|shared)
[pte_basic_tests ]: Validating PTE basic (exec|shared)
[pte_basic_tests ]: Validating PTE basic (read|exec|shared)
[pte_basic_tests ]: Validating PTE basic (write|exec|shared)
[pte_basic_tests ]: Validating PTE basic (read|write|exec|shared)
This adds a missing argument 'struct mm_struct *' in pud_basic_tests() test
. This never got exposed before as PUD based THP is available only on X86
platform where mm_pmd_folded(mm) call gets macro replaced without requiring
the mm_struct i.e __is_defined(__PAGETABLE_PMD_FOLDED).
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
Reviewed-by: Steven Price
---
mm/debug_vm_pgtable.c | 47 ---
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index a5be11210597..92b4a53d622b 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -58,11 +58,13 @@
#define RANDOM_ORVALUE (GENMASK(BITS_PER_LONG - 1, 0) & ~ARCH_SKIP_MASK)
#define RANDOM_NZVALUEGENMASK(7, 0)
-static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pte_basic_tests(unsigned long pfn, int idx)
{
+ pgprot_t prot = protection_map[idx];
pte_t pte = pfn_pte(pfn, prot);
+ unsigned long val = idx, *ptr =
- pr_debug("Validating PTE basic\n");
+ pr_debug("Validating PTE basic (%pGv)\n", ptr);
WARN_ON(!pte_same(pte, pte));
WARN_ON(!pte_young(pte_mkyoung(pte_mkold(pte;
WARN_ON(!pte_dirty(pte_mkdirty(pte_mkclean(pte;
@@ -130,14 +132,16 @@ static void __init pte_savedwrite_tests(unsigned long
pfn, pgprot_t prot)
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pmd_basic_tests(unsigned long pfn, int idx)
{
+ pgprot_t prot = protection_map[idx];
pmd_t pmd = pfn_pmd(pfn, prot);
+ unsigned long val = idx, *ptr =
if (!has_transparent_hugepage())
return;
- pr_debug("Validating PMD basic\n");
+ pr_debug("Validating PMD basic (%pGv)\n", ptr);
WARN_ON(!pmd_same(pmd, pmd));
WARN_ON(!pmd_young(pmd_mkyoung(pmd_mkold(pmd;
WARN_ON(!pmd_dirty(pmd_mkdirty(pmd_mkclean(pmd;
@@ -251,14 +255,16 @@ static void __init pmd_savedwrite_tests(unsigned long
pfn, pgprot_t prot)
}
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
-static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn,
int idx)
{
+ pgprot_t prot = protection_map[idx];
pud_t pud = pfn_pud(pfn, prot);
+ unsigned long val = idx, *ptr =
if (!has_transparent_hugepage())
return;
- pr_debug("Validating PUD basic\n");
+ pr_debug("Validating PUD basic (%pGv)\n", ptr);
WARN_ON(!pud_same(pud, pud));
WARN_ON(!pud_young(pud_mkyoung(pud_mkold(pud;
WARN_ON(!pud_write(pud_mkwrite(pud_wrprotect(pud;
@@ -362,7 +368,7 @@ static void __init pud_huge_tests(pud_t *pudp, unsigned
long pfn, pgprot_t prot)
#endif /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
#else /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
-static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
+static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn,
int idx) { }
static void __init pud_advanced_tests(struct mm_struct *mm,
struct vm_area_struct *vma,
Re: [PATCH v2] fbdev: aty: SPARC64 requires FB_ATY_CT
On Fri, Nov 27, 2020 at 4:18 AM Randy Dunlap wrote:
> It looks like SPARC64 requires FB_ATY_CT to build without errors,
> so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
> instead of using "default y if SPARC64 && PCI", which is not strong
> enough to prevent build errors.
>
> As it currently is, FB_ATY_CT can be disabled, resulting in build
> errors:
>
> ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko]
> undefined!
> ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
>
> Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
> Signed-off-by: Randy Dunlap
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Hi Andrew, > > (A side question - DSA uses switchdev, so when one shall use > > switchdev standalone?) > > DSA gives you a framework for an Ethernet switch connected to a host > via Ethernet for the data plane. Generally, that Ethernet link to the > switch is a MAC to MAC connection. It can be PHY to PHY. But those are > just details. The important thing is you use an Ethernet driver on the > host. > > If you look at pure switchdev devices, they generally DMA frames > directly into the switch. There is either one DMA queue per switch > port, or there is a way to multiplex frames over one DMA queue, > generally by additional fields in the buffer descriptor. > > For this device, at the moment, it is hard to say which is the best > fit. A lot will depend on how the FEC driver works, if you can reuse > it, while still having the degree of control you need over the DMA > channel. If you can reuse the FEC driver, then a DSA driver might > work. If the coupling it too loose, and you have to take control of > the DMA, then a pure switchdev driver seems more appropriate. > > Andrew > Thanks for the detailed explanation. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpeKAUQt4NyC.pgp Description: OpenPGP digital signature
Re: boot interrupt quirk (also in 4.19.y) breaks serial ports (was: [PATCH v2 0/2] pci: Add boot interrupt quirk mechanism for Xeon chipsets)
Hi tglx, On 11/27/20 12:45 AM, Thomas Gleixner wrote: > Stefan, > > On Wed, Nov 25 2020 at 14:41, Stefan Bühler wrote: >> On 11/25/20 12:54 PM, Thomas Gleixner wrote: >>> On Wed, Sep 16 2020 at 12:12, Stefan Bühler wrote: >>> Can you please provide the output of: >>> >>> for ID in 05:00.0 06:00.0 06:00.1 06:01.0 06:01.1; do lspci -s $ID -vvv; >>> done >> >> 05:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI >> Bridge (rev aa) (prog-if 00 [Normal decode]) >> ... >> Capabilities: > > Can you please run this as root so the Capabilities are accessible? My bad, sorry. I did intend to run it as root, but should have checked the output. Again see attached file. While we're at it: the EEPROM for the PEX8112 is: 5a 03 3c 00 10 00 00 00 00 00 00 00 b5 10 12 81 |Z.<.| 0010 64 00 20 00 00 00 00 01 04 00 01 00 0c 10 00 fe |d. .| 0020 fe 03 20 10 f0 10 00 00 00 10 33 00 00 00 70 00 |.. ...3...p.| 0030 00 00 11 00 48 00 00 00 00 00 34 00 50 00 00 00 |H.4.P...| 0040 04 00 55 66 77 88 |..Ufw.| 0046 (This is what the firmware tool provided to me writes, although I think the cards usually came pre-flashed with it. They gave me the tool because on some cards the second function on OX16PCI954 was sometimes uninitialized, came up with device id 0x9511 "8-bit bus" (PCI_DEVICE_ID_OXSEMI_16PCI95N) and the kernel tries to treat it as UART too.) I think some time ago I found a PDF to decode this here: https://www.broadcom.com/products/pcie-switches-bridges/pcie-bridges/pex8112#documentation But the broadcom site is completely broken right now (at least for me; there own search for "PEX 8112" links it, but then it says "not found"). Anyway, back then I decoded this to: - `0x5A 0x03`: Magic Header, contains register and shared memory settings - `0x003C` = 60 bytes for configs (10 registers): - `@0x0010`: `0x` -- BAR0: Locate anywhere in 32-bit - `@0x`: `0x811210B5` -- Vendor `10B5`, Device `8112` (default) - `@0x0064`: `0x0020` -- Device Capability: Enable "Support 8-bit Tag" field - `@0x0100`: `0x00010004` -- Power Budget Enhanced Capability Header (default) - `@0x100C`: `0x03FEFE00` -- PCI Control: - PCI-To-PCI Express Retry Count set to 0xFE (default: `0x80`) - PCI Express-to-PCI Retry Count set to 0xFE (default: `0x00`) - `@0x1020`: `0x10F0` -- GPIO Control - GPIO[1-3] Output enable (GPIO[0] is Output enabled by default) - GPIO Diagnostic Select: `10b` (default: `01b`) - `@0x1000`: `0x0033` -- Device Initialization (default) - `@0x0070`: `0x0011` -- Link control: default - `@0x0048`: `0x` -- Device-Specific Control (default 0) - `@0x0034`: `0x0050` -- PCI Capability pointer `0x50` (default: `0x40`) - Skips (disables) Power Management Capability - Remaining: MSI and PCI Express - `0x0004` bytes for shared memory: - `0x55`, `0x66`, `0x77`, `0x88` TLDR: the most notable part probably being "disabling Power Management Capability" by the EEPROM. cheers, Stefan 05:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Physical Slot: 1 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [60] Express (v1) PCI-Express to PCI/PCI-X Bridge, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- SlotPowerLimit 26.000W DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop- BrConfRtry- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Power Budgeting 06:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Re: [PATCH bpf-next 2/2] bpf: Add a selftest for the tracing bpf_get_socket_cookie
On Thu, 2020-11-26 at 23:56 -0800, Yonghong Song wrote: > > On 11/26/20 9:02 AM, Florent Revest wrote: > > This builds up on the existing socket cookie test which checks > > whether > > the bpf_get_socket_cookie helpers provide the same value in > > cgroup/connect6 and sockops programs for a socket created by the > > userspace part of the test. > > > > Adding a tracing program to the existing objects requires a > > different > > attachment strategy and different headers. > > > > Signed-off-by: Florent Revest > > --- > > .../selftests/bpf/progs/socket_cookie_prog.c | 41 > > --- > > .../selftests/bpf/test_socket_cookie.c| 18 +--- > > Do you think it is possible to migrate test_socket_cookie.c to > selftests/bpf/prog_tests so it can be part of test_progs so > it will be regularly exercised? I suppose it's possible, I can give it a try :)
Re: [PATCH 01/16] mfd: bcm590xx: drop of_match_ptr from of_device_id table
On Fri, 27 Nov 2020, Krzysztof Kozlowski wrote:
> On Fri, 27 Nov 2020 at 09:06, Lee Jones wrote:
> >
> > On Fri, 20 Nov 2020, Krzysztof Kozlowski wrote:
> >
> > > The driver can match only via the DT table so the table should be always
> > > used and the of_match_ptr does not have any sense (this also allows ACPI
> > > matching via PRP0001, even though it is not relevant here). This fixes
> > > compile warning (!CONFIG_OF on x86_64):
> > >
> > > drivers/mfd/bcm590xx.c:95:34: warning: ‘bcm590xx_of_match’ defined but
> > > not used [-Wunused-const-variable=]
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > > ---
> > > drivers/mfd/bcm590xx.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Couple of small points:
> >
> > - Patch-sets, particularly large ones should have a cover letter.
> > - Subject lines follow English grammar conventions and should start
> > with an uppercase character.
>
> Thanks for fixing this. I am not a native English speaker and I make
> mistakes. Either it is a grammar or convention mistake, I would
> appreciate it if you point them out, so I could learn from them.
> About the "start with an uppercase character", I actually on purpose
> changed my approach some time ago after seeing more senior kernel
> developers using this method (see commits from Linus Torvalds, Andrew
> Morton). After the subsystem prefix "mfd: " they start with
> lowercase. If you still insist that commit titles in MFD subsystem
> should use capital letter after the prefix, I will try to remember and
> follow this approach when sending patches to you.
It's a per-subsystem convention thing.
Looks like some use capitals, some don't (MFD does):
$ for f in `ls --color=never drivers`; do echo -ne "$f: \t"; git --no-pager log
--no-merges --oneline -n1 -- drivers/$f; done
accessibility: d412275444279 speakup: Do not let the line discipline be used
several times
acpi: 774c4a3b5e5fd ACPI/IORT: Fix doc warnings in iort.c
amba: 06f3a5a4cbb5f ARM: tegra: Replace zero-length array with
flexible-array
android:1987f112f1425 binder: add trace at free transaction.
ata:8e4c309f9f33b ata: sata_nv: Fix retrieving of active qcs
atm:2de680dea6a88 atm: lanai: Remove in_interrupt() usage
auxdisplay: 351dcacc6d774 auxdisplay: panel: Remove redundant charlcd_ops
structures
base: e6e9354b58307 regmap: Remove duplicate `type` field from regmap
`regcache_sync` trace event
bcma: 703314b2db3bb bcma: use semicolons rather than commas to
separate statements
block: 21f7748069e02 zram: support page writeback
bluetooth: d45330536ce31 Bluetooth: btmtksdio: Add the missed
release_firmware() in mtk_setup_firmware()
bus:65fb73676112f bus: ti-sysc: suppress err msg for timers used as
clockevent/source
cdrom: faf041388c28e gdrom: use bdev_check_media_change
char: a24d22b225ce1 crypto: sha - split sha.h into sha1.h and sha2.h
clk:44a9e78f92428 clk: samsung: Prevent potential endless loop in
the PLL ops
clocksource:8da10e545406b clocksource/drivers/cadence_ttc: Fix memory leak
in ttc_setup_clockevent()
connector: fe6bc89abe2c2 connector: simplify the return expression of
cn_add_callback()
counter:271b339236e1c counter/ti-eqep: Fix regmap max_register
cpufreq:f943849f72068 cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK
cpuidle:c39de538a06e7 cpuidle: tegra: Annotate
tegra_pm_set_cpu_in_lp2() with RCU_NONIDLE
crypto: 732b764099f65 crypto: sun8i-ce - fix two error path's memory
leak
dax:99a33a943cebd vm_ops: rename .split() callback to .may_split()
dca:0548745fa335a dca: Use PTR_ERR_OR_ZERO() to simplify code
devfreq:98fd9972ed60d PM / devfreq: tegra20: Deprecate in a favor of
emc-stat based driver
dio:fe557319aa06c maccess: rename probe_kernel_{read,write} to
copy_{from,to}_kernel_nofault
dma:5d051f37f49d5 dmaengine: ti: drop of_match_ptr and mark
of_device_id table as maybe unused
dma-buf:1faad6c51a0cf dma-buf: use krealloc_array()
edac: 47a3f41802d85 edac: ghes: use krealloc_array()
eisa: a7f7f6248d974 treewide: replace '---help---' in Kconfig files
with 'help'
extcon: 54589b557a8dd extcon: fsa9480: Support TI TSU6111 variant
firewire: c51a9868d361a firewire-ohci: use dma_alloc_pages
firmware: ad3f23269250f treewide: remove stringification from __alias
macro definition
fpga: aaf8fe39c9521 Revert "fpga: dfl: fix the definitions of type &
feature_id for dfl devices"
fsi:4a851d714eade fsi: aspeed: Support CFAM reset GPIO
gnss: a7f7f6248d974 treewide: replace '---help---' in Kconfig files
with 'help'
gpio: 9dd47d88ba6d5 gpio: xilinx: utilize generic bitmap_get_value
and _set_value
gpu:31bef3efe6255 drm/amd/display/dc/basics/vector: Make local
function
Re: [PATCH v3 7/8] regulator: mt6359: Add support for MT6359P regulator
On Mon, 23 Nov 2020, Hsin-Hsiung Wang wrote: > The MT6359P is a eco version for MT6359 regulator. > We add support based on MT6359 regulator driver. > > Signed-off-by: Hsin-Hsiung Wang > --- > drivers/regulator/mt6359-regulator.c | 413 - > include/linux/mfd/mt6359p/registers.h | 249 + > include/linux/regulator/mt6359-regulator.h | 1 + > 3 files changed, 658 insertions(+), 5 deletions(-) > create mode 100644 include/linux/mfd/mt6359p/registers.h For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] drm: bridge: adv7511: Remove redundant null check before clk_disable_unprepare
Because clk_disable_unprepare() already checked NULL clock parameter, so the additional check is unnecessary, just remove them. Signed-off-by: Xu Wang --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index a0d392c338da..76555ae64e9c 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1292,8 +1292,7 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) err_unregister_cec: i2c_unregister_device(adv7511->i2c_cec); - if (adv7511->cec_clk) - clk_disable_unprepare(adv7511->cec_clk); + clk_disable_unprepare(adv7511->cec_clk); err_i2c_unregister_packet: i2c_unregister_device(adv7511->i2c_packet); err_i2c_unregister_edid: @@ -1311,8 +1310,7 @@ static int adv7511_remove(struct i2c_client *i2c) if (adv7511->type == ADV7533 || adv7511->type == ADV7535) adv7533_detach_dsi(adv7511); i2c_unregister_device(adv7511->i2c_cec); - if (adv7511->cec_clk) - clk_disable_unprepare(adv7511->cec_clk); + clk_disable_unprepare(adv7511->cec_clk); adv7511_uninit_regulators(adv7511); -- 2.17.1
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On Thu, 2020-11-26 at 23:35 -0800, Yonghong Song wrote:
> On 11/26/20 8:57 AM, Florent Revest wrote:
> > +BPF_CALL_5(bpf_kallsyms_lookup, u64, address, char *, symbol, u32,
> > symbol_size,
> > + char *, module, u32, module_size)
> > +{
> > + char buffer[KSYM_SYMBOL_LEN];
> > + unsigned long offset, size;
> > + const char *name;
> > + char *modname;
> > + long ret;
> > +
> > + name = kallsyms_lookup(address, , , ,
> > buffer);
> > + if (!name)
> > + return -EINVAL;
> > +
> > + ret = strlen(name) + 1;
> > + if (symbol_size) {
> > + strncpy(symbol, name, symbol_size);
> > + symbol[symbol_size - 1] = '\0';
> > + }
> > +
> > + if (modname && module_size) {
> > + strncpy(module, modname, module_size);
> > + module[module_size - 1] = '\0';
>
> In this case, module name may be truncated and user did not get any
> indication from return value. In the helper description, it is
> mentioned that module name currently is most 64 bytes. But from UAPI
> perspective, it may be still good to return something to let user
> know the name is truncated.
>
> I do not know what is the best way to do this. One suggestion is
> to break it into two helpers, one for symbol name and another
> for module name. What is the use cases people want to get both
> symbol name and module name and is it common?
Fair, I can split this into two helpers :) The lookup would be done
twice but I don't think that's a big deal.
Re: [PATCH] scsi: zfcp: fix use-after-free in zfcp_unit_remove
On 11/26/20 4:12 PM, Benjamin Block wrote:
On Thu, Nov 26, 2020 at 08:07:32PM +0800, Qinglang Miao wrote:
在 2020/11/26 17:42, Benjamin Block 写道:
On Thu, Nov 26, 2020 at 09:13:53AM +0100, Cornelia Huck wrote:
On Thu, 26 Nov 2020 09:27:41 +0800
Qinglang Miao wrote:
在 2020/11/26 1:06, Benjamin Block 写道:
On Fri, Nov 20, 2020 at 03:48:54PM +0800, Qinglang Miao wrote:
Let's go by example. If we assume the reference count of `unit->dev` is
R, and the function starts with R = 1 (otherwise the deivce would've
been freed already), we get:
int zfcp_unit_remove(struct zfcp_port *port, u64 fcp_lun)
{
struct zfcp_unit *unit;
struct scsi_device *sdev;
write_lock_irq(>unit_list_lock);
// unit->dev (R = 1)
unit = _zfcp_unit_find(port, fcp_lun);
// get_device(>dev)
// unit->dev (R = 2)
if (unit)
list_del(>list);
write_unlock_irq(>unit_list_lock);
if (!unit)
return -EINVAL;
sdev = zfcp_unit_sdev(unit);
if (sdev) {
scsi_remove_device(sdev);
scsi_device_put(sdev);
}
// unit->dev (R = 2)
put_device(>dev);
// unit->dev (R = 1)
device_unregister(>dev);
// unit->dev (R = 0)
return 0;
}
If we now apply this patch, we'd end up with R = 1 after
`device_unregister()`, and the device would not be properly removed.
If you still think that's wrong, then you'll need to better explain why.
Hi Banjamin and Cornelia,
Your replies make me reliaze that I've been holding a mistake understanding
of put_device() as well as reference count.
Thanks for you two's patient explanation !!
BTW, should I send a v2 on these two patches to move the position of
put_device()?
Feel free to do so.
I think having the `put_device()` call after `device_unregister()` in
both `zfcp_unit_remove()` and `zfcp_sysfs_port_remove_store()` is more
natural, because it ought to be the last time we touch the object in
both functions.
If you move put_device(), you could add a comment like we did here to explain
which (hidden) get_device is undone:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/scsi?id=ef4021fe5fd77ced0323cede27979d80a56211ca
("scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs)")
So in this patch it could be:
put_device(>dev); /* undo _zfcp_unit_find() */
And in the other patch it could be:
put_device(>dev); /* undo zfcp_get_port_by_wwpn() */
Then it would be clearer next time somebody looks at the code.
Especially for the other patch on zfcp_sysfs_port_remove_store() moving the
put_device(>dev) to at least *after* the call of
zfcp_erp_port_shutdown(port, 0, "syprs_1") would make the code cleaner to me.
Along the idead of passing the port to zfcp_erp_port_shutdown with the
reference we got from zfcp_get_port_by_wwpn(). That said, the current code is
of course still correct as we currently have the port ref of the earlier
device_register so passing the port to zfcp_erp_port_shutdown() is safe.
If we wanted to make the gets and puts nicely nested, then we could move the
puts to just before the device_unregister, but that's bike shedding:
device_register() --+
get_device() --+ |
put_device() --+ |
device_unregister() --+
Benjamin's suggested move location works for me, too. After all, the kdoc of
device_unregister explicitly mentions the possibility that other refs might
continue to exist after device_unregister was called:
device_register() --+
get_device() -|--+
device_unregister() --+ |
put_device() +
--
Mit freundlichen Gruessen / Kind regards
Steffen Maier
Linux on IBM Z Development
https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: linux-next: build failure after merge of the dma-mapping tree
On Fri, Nov 27, 2020 at 05:58:01PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the dma-mapping tree, today's linux-next build (powerpc64 > allnoconfig) failed like this: I'm looking into fixing this now, but how do you generate a powerpc64 allnoconfig? My attempts so far either create a ppc32 one or fail entirely.
Re: [PATCH bpf-next v3 5/6] bpf: Add an iterator selftest for bpf_sk_storage_get
On Thu, 2020-11-26 at 23:00 -0800, Yonghong Song wrote:
> On 11/26/20 8:44 AM, Florent Revest wrote:
> > +SEC("iter/task_file")
> > +int fill_socket_owner(struct bpf_iter__task_file *ctx)
> > +{
> > + struct task_struct *task = ctx->task;
> > + struct file *file = ctx->file;
> > + struct socket *sock;
> > + int *sock_tgid;
> > +
> > + if (!task || !file || task->tgid != task->pid)
>
> task->tgid != task->pid is not needed here.
> The task_file iterator already tries to skip task with task->pid
> if its file table is the same as task->tgid.
Good to know!
Re: [PATCH 7/8] rtc: rework rtc_register_device() resource management
On Fri, Nov 27, 2020 at 10:16 AM Lee Jones wrote: > > > > On Mon, 9 Nov 2020 at 16:34, Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> rtc_register_device() is a managed interface but it doesn't use devres >> by itself - instead it marks an rtc_device as "registered" and the devres >> callback for devm_rtc_allocate_device() takes care of resource release. >> >> This doesn't correspond with the design behind devres where managed >> structures should not be aware of being managed. The correct solution >> here is to register a separate devres callback for unregistering the >> device. >> >> While at it: rename rtc_register_device() to devm_rtc_register_device() >> and add it to the list of managed interfaces in devres.rst. This way we >> can avoid any potential confusion of driver developers who may expect >> there to exist a corresponding unregister function. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> .../driver-api/driver-model/devres.rst| 1 + >> arch/alpha/kernel/rtc.c | 2 +- >> drivers/mfd/menelaus.c| 2 +- > > > This patch should have been sent to and Acked by MFD too. > Sorry Lee, I missed the fact that there were changes outside of drivers/rtc/. Other than skipping the MFD maintainer - do you see anything wrong in that bit? Bartosz
[PATCH] drm: bridge: dw-hdmi: Remove redundant null check before clk_disable_unprepare
Because clk_disable_unprepare() already checked NULL clock parameter, so the additional check is unnecessary, just remove them. Signed-off-by: Xu Wang --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 0c79a9ba48bb..dda4fa9a1a08 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -3440,8 +3440,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, err_iahb: clk_disable_unprepare(hdmi->iahb_clk); - if (hdmi->cec_clk) - clk_disable_unprepare(hdmi->cec_clk); + clk_disable_unprepare(hdmi->cec_clk); err_isfr: clk_disable_unprepare(hdmi->isfr_clk); err_res: @@ -3465,8 +3464,7 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi) clk_disable_unprepare(hdmi->iahb_clk); clk_disable_unprepare(hdmi->isfr_clk); - if (hdmi->cec_clk) - clk_disable_unprepare(hdmi->cec_clk); + clk_disable_unprepare(hdmi->cec_clk); if (hdmi->i2c) i2c_del_adapter(>i2c->adap); -- 2.17.1
Re: [PATCH v6 1/1] arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile
On 30/10/2020 10:22, Seiya Wang wrote:
Add basic chip support for Mediatek MT8192
Signed-off-by: Seiya Wang
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 29 ++
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 512
3 files changed, 542 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8192-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8192.dtsi
Applied to v5.10-next/dts64
Thanks!
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 3ee682c266cc..b431ee2d6cac 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -12,4 +12,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
new file mode 100644
index ..0205837fa698
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Seiya Wang
+ */
+/dts-v1/;
+#include "mt8192.dtsi"
+
+/ {
+ model = "MediaTek MT8192 evaluation board";
+ compatible = "mediatek,mt8192-evb", "mediatek,mt8192";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
new file mode 100644
index ..e12e024de122
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -0,0 +1,512 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Seiya Wang
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8192";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clk26m: oscillator0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "clk26m";
+ };
+
+ clk32k: oscillator1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "clk32k";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x000>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <_0>;
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x100>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <_0>;
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x200>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <_0>;
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x300>;
+ enable-method = "psci";
+ clock-frequency = <170100>;
+ next-level-cache = <_0>;
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu4: cpu@400 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a76";
+ reg = <0x400>;
+ enable-method = "psci";
+ clock-frequency = <217100>;
+ next-level-cache = <_1>;
+ capacity-dmips-mhz = <1024>;
+ };
+
+ cpu5: cpu@500 {
+ device_type = "cpu";
+
Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Hi Andrew, > > > I would push back and say that the switch offers bridge > > > acceleration for the FEC. > > > > Am I correct, that the "bridge acceleration" means in-hardware > > support for L2 packet bridging? > > You should think of the hardware as an accelerator, not a switch. The > hardware is there to accelerate what linux can already do. You setup a > software bridge in linux, and then offload L2 switching to the > accelerator. You setup vlans in linux, and then offload the filtering > of them to the accelerator. If there is something linux can do, but > the hardware cannot accelerate, you leave linux to do it in software. Ok. > > > Do you propose to catch some kind of notification when user calls: > > > > ip link add name br0 type bridge; ip link set br0 up; > > ip link set lan1 up; ip link set lan2 up; > > ip link set lan1 master br0; ip link set lan2 master br0; > > bridge link > > > > And then configure the FEC driver to use this L2 switch driver? > > That is what switchdev does. There are various hooks in the network > stack which call into switchdev to ask it to offload operations to the > accelerator. Ok. > > > The differences from "normal" DSA switches: > > > > 1. It uses mapped memory (for its register space) for > > configuration/statistics gathering (instead of e.g. SPI, I2C) > > That does not matter. And there are memory mapped DSA switches. The > DSA framework puts no restrictions on how the control plane works. > > > (Of course the "Section 32.5.8.2" is not available) > > It is in the Vybrid datasheet :-) Hmm... I cannot find such chapter in the official documentation from NXP: "VFxxx Controller Reference Manual, Rev. 0, 10/2016" Maybe you have more verbose version? Could you share how the document is named? > >Andrew Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpkJ_kZQiYb5.pgp Description: OpenPGP digital signature
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On Fri, 2020-11-27 at 03:32 +0100, KP Singh wrote:
> > + ret = strlen(name) + 1;
> > + if (symbol_size) {
> > + strncpy(symbol, name, symbol_size);
> > + symbol[symbol_size - 1] = '\0';
> > + }
> > +
> > + if (modname && module_size) {
> > + strncpy(module, modname, module_size);
>
> The return value does not seem to be impacted by the truncation of
> the module name, I wonder if it is better to just use a single
> buffer.
>
> For example, the proc kallsyms shows symbols as:
>
> [module_name]
>
> https://github.com/torvalds/linux/blob/master/kernel/kallsyms.c#L648
>
> The square brackets do seem to be a waste here, so maybe we could use
> a single character as a separator?
I prefer Yongonhong's suggestion of having two helpers. This gives more
control to the BPF program. For example, they could decide to audit
only addresses coming from a module, and that would be easier to do
with two helpers than by parsing a string in BPF.
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On Fri, 2020-11-27 at 10:25 +0100, Florent Revest wrote: > I prefer Yongonhong's suggestion of having two helpers. Argh! I hit enter too fast! Yonghong*, sorry :|
Re: [RFC 1/2] dt-bindings: thermal: sprd: Add virtual thermal documentation
On 11/27/20 8:35 AM, gao.yunxi...@gmail.com wrote:
From: "jeson.gao"
virtual thermal node definition description in dts file
Signed-off-by: jeson.gao
---
.../thermal/sprd-virtual-thermal.yaml | 38 +++
1 file changed, 38 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
diff --git
a/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
b/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
new file mode 100644
index ..3e3d2282e2a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sprd-virtual-thermal.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/sprd-virtual-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum virtual thermal driver bindings
+
+maintainers:
+ - Yunxiao Gao
+
+properties:
+ compatible:
+const: sprd,virtual-thermal
+
+ reg:
+description: specify the virtual sensor id.
+maxItems: 1
+
+ thmzone-names:
+description: specify per-core thermal zone name.
+
+required:
+ - compatible
+ - reg
+ - thmzone-names
+
+additionalProperties: false
+
+examples:
+ - |
+virtual_sensor: virtual-sensor@1 {
+ compatible = "sprd,virtual-thermal";
+ reg = <1>;
+ thmzone-names = "ank0-thmzone","ank1-thmzone","ank2-thmzone",
+
"ank3-thmzone","ank4-thmzone","ank5-thmzone","prometheus6-tzone0",
+ "prometheus6-tzone1","prometheus7-thmzone";
+};
It's coming back. There were attempts to solve this problem.
Javi tried to solved this using hierarchical thermal zones [1].
It was even agreed (IIRC during LPC) but couldn't continue. Then Eduardo
was going to continue this (last message at [3]). Unfortunately,
development stopped.
I also have out-of-tree similar implementation for my Odroid-xu4,
which does no have an 'SoC' sensor, but have CPU sensors and needs
some aggregation function to get temperature.
I can pick up Javi's patches and continue 'hierarchical thermal zones'
approach.
Javi, Daniel, Rui what do you think?
Regards,
Lukasz
[1] https://lwn.net/Articles/666015/
[2]
https://patchwork.kernel.org/project/linux-pm/patch/1448464186-26289-2-git-send-email-javi.mer...@arm.com/
[3]
https://patchwork.kernel.org/project/linux-pm/patch/1448464186-26289-3-git-send-email-javi.mer...@arm.com/
[4]
https://patchwork.kernel.org/project/linux-pm/patch/1448464186-26289-4-git-send-email-javi.mer...@arm.com/
[5]
https://patchwork.kernel.org/project/linux-pm/patch/1448464186-26289-5-git-send-email-javi.mer...@arm.com/
Re: [PATCH v15 00/26] Control-flow Enforcement: Shadow Stack
On Tue, Nov 10, 2020 at 08:21:45AM -0800, Yu-cheng Yu wrote: > Control-flow Enforcement (CET) is a new Intel processor feature that blocks > return/jump-oriented programming attacks. Details are in "Intel 64 and > IA-32 Architectures Software Developer's Manual" [1]. > > CET can protect applications and the kernel. This series enables only > application-level protection, and has three parts: > > - Shadow stack [2], > - Indirect branch tracking [3], and > - Selftests [4]. > > I have run tests on these patches for quite some time, and they have been > very stable. Linux distributions with CET are available now, and Intel > processors with CET are becoming available. It would be nice if CET > support can be accepted into the kernel. I will be working to address any > issues should they come up. > Is there a way to run these patches for testing? Bochs emulation or anything else? I presume you've been testing against violations of CET in user space? Can you share your testing? Balbir Singh.
Re: [PATCH v3 1/8] mfd: mt6358: refine interrupt code
On Mon, 23 Nov 2020, Hsin-Hsiung Wang wrote: > This patch refines the interrupt related code to support new chips. > > Signed-off-by: Hsin-Hsiung Wang > --- > drivers/mfd/mt6358-irq.c| 65 +++-- > include/linux/mfd/mt6358/core.h | 8 ++-- > 2 files changed, 41 insertions(+), 32 deletions(-) For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] usb: cdns3: Fix hardware based role switch
Hi Peter,
On 25/11/2020 14:49, Roger Quadros wrote:
Hardware based role switch is broken as the driver always skips it.
Fix this by registering for SW role switch only if 'usb-role-switch'
property is present in the device tree.
Fixes: 50642709f659 ("usb: cdns3: core: quit if it uses role switch class")
Signed-off-by: Roger Quadros
Can you please pick this up for -rc cycle, else otg will be broken for us in
v5.10 release.
Thanks.
cheers,
-roger
---
drivers/usb/cdns3/core.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
index a0f73d4711ae..170deb3eacf0 100644
--- a/drivers/usb/cdns3/core.c
+++ b/drivers/usb/cdns3/core.c
@@ -427,7 +427,6 @@ static irqreturn_t cdns3_wakeup_irq(int irq, void *data)
*/
static int cdns3_probe(struct platform_device *pdev)
{
- struct usb_role_switch_desc sw_desc = { };
struct device *dev = >dev;
struct resource *res;
struct cdns3 *cdns;
@@ -529,18 +528,21 @@ static int cdns3_probe(struct platform_device *pdev)
if (ret)
goto err2;
- sw_desc.set = cdns3_role_set;
- sw_desc.get = cdns3_role_get;
- sw_desc.allow_userspace_control = true;
- sw_desc.driver_data = cdns;
- if (device_property_read_bool(dev, "usb-role-switch"))
+ if (device_property_read_bool(dev, "usb-role-switch")) {
+ struct usb_role_switch_desc sw_desc = { };
+
+ sw_desc.set = cdns3_role_set;
+ sw_desc.get = cdns3_role_get;
+ sw_desc.allow_userspace_control = true;
+ sw_desc.driver_data = cdns;
sw_desc.fwnode = dev->fwnode;
- cdns->role_sw = usb_role_switch_register(dev, _desc);
- if (IS_ERR(cdns->role_sw)) {
- ret = PTR_ERR(cdns->role_sw);
- dev_warn(dev, "Unable to register Role Switch\n");
- goto err3;
+ cdns->role_sw = usb_role_switch_register(dev, _desc);
+ if (IS_ERR(cdns->role_sw)) {
+ ret = PTR_ERR(cdns->role_sw);
+ dev_warn(dev, "Unable to register Role Switch\n");
+ goto err3;
+ }
}
if (cdns->wakeup_irq) {
@@ -582,7 +584,8 @@ static int cdns3_probe(struct platform_device *pdev)
return 0;
err4:
cdns3_drd_exit(cdns);
- usb_role_switch_unregister(cdns->role_sw);
+ if (cdns->role_sw)
+ usb_role_switch_unregister(cdns->role_sw);
err3:
set_phy_power_off(cdns);
err2:
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/2] mfd: fix spelling mistakes
On Tue, 24 Nov 2020, Michael Klein wrote: The subject line needs to be more forthcoming. What spelling mistakes are you fixing? Which files are being changed? > Signed-off-by: Michael Klein > --- > drivers/regulator/da9055-regulator.c | 4 ++-- > include/linux/mfd/da9055/reg.h | 4 ++-- > include/linux/mfd/si476x-core.h | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) Let's have a patch for each of these, with proper subject lines. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 2/4] x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ
Hey Dave Marin,
On 11/26/20 6:44 PM, Borislav Petkov wrote:
> On Thu, Nov 19, 2020 at 11:02:35AM -0800, Chang S. Bae wrote:
>> Historically, signal.h defines MINSIGSTKSZ (2KB) and SIGSTKSZ (8KB), for
>> use by all architectures with sigaltstack(2). Over time, the hardware state
>> size grew, but these constants did not evolve. Today, literal use of these
>> constants on several architectures may result in signal stack overflow, and
>> thus user data corruption.
>>
>> A few years ago, the ARM team addressed this issue by establishing
>> getauxval(AT_MINSIGSTKSZ), such that the kernel can supply at runtime value
>> that is an appropriate replacement on the current and future hardware.
>>
>> Add getauxval(AT_MINSIGSTKSZ) support to x86, analogous to the support
>> added for ARM in commit 94b07c1f8c39 ("arm64: signal: Report signal frame
>> size to userspace via auxv").
>
> I don't see it documented here:
>
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/getauxval.3
>
> Dunno, now that two architectures will have it, maybe that is good
> enough reason to document it.
>
> Adding Michael.
Commit 94b07c1f8c39 was your, Dave. Might I convince you to write a
patch for getauxval(3)?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [RESEND PATCH v4 2/6] mfd: ahc1ec0: Add Advantech EC include file used by dt-bindings
On Wed, 25 Nov 2020, Shihlun Lin wrote: > This files defines the sud-device types and hwmon profiles support by > Advantech embedded controller. > > Signed-off-by: Shihlun Lin > --- > include/dt-bindings/mfd/ahc1ec0.h | 25 + > 1 file changed, 25 insertions(+) > create mode 100644 include/dt-bindings/mfd/ahc1ec0.h For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: linux-next: build failure after merge of the dma-mapping tree
I fixed this as shown: diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c index c724548ca295c0..111249fd619de8 100644 --- a/arch/powerpc/kernel/dma-iommu.c +++ b/arch/powerpc/kernel/dma-iommu.c @@ -10,6 +10,7 @@ #include #include +#ifdef CONFIG_ARCH_HAS_DMA_MAP_DIRECT #define can_map_direct(dev, addr) \ ((dev)->bus_dma_limit >= phys_to_dma((dev), (addr))) @@ -64,6 +65,7 @@ bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg, return true; } +#endif /* CONFIG_ARCH_HAS_DMA_MAP_DIRECT */ /* * Generic iommu implementation
Re: [PATCH v2 3/5] memory: renesas-rpc-if: Fix a reference leak in rpcif_probe()
On Thu, Nov 26, 2020 at 8:12 PM Lad Prabhakar
wrote:
> Release the node reference by calling of_node_put(flash) in the probe.
>
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Reported-by: Pavel Machek
> Signed-off-by: Lad Prabhakar
> Cc: sta...@vger.kernel.org
> Reviewed-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/5] memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()
On Thu, Nov 26, 2020 at 8:12 PM Lad Prabhakar
wrote:
> In the error path of rpcif_manual_xfer() the value of ret is overwritten
> by value returned by reset_control_reset() function and thus returning
> incorrect value to the caller.
>
> This patch makes sure the correct value is returned to the caller of
> rpcif_manual_xfer() by dropping the overwrite of ret in error path.
> Also now we ignore the value returned by reset_control_reset() in the
> error path and instead print a error message when it fails.
>
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Reported-by: Pavel Machek
> Signed-off-by: Lad Prabhakar
> Cc: sta...@vger.kernel.org
> Reviewed-by: Sergei Shtylyov
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] net/ipv6: propagate user pointer annotation
For IPV6_2292PKTOPTIONS, do_ipv6_getsockopt() stores the user pointer
optval in the msg_control field of the msghdr.
Hence, sparse rightfully warns at ./net/ipv6/ipv6_sockglue.c:1151:33:
warning: incorrect type in assignment (different address spaces)
expected void *msg_control
got char [noderef] __user *optval
Since commit 1f466e1f15cf ("net: cleanly handle kernel vs user buffers for
->msg_control"), user pointers shall be stored in the msg_control_user
field, and kernel pointers in the msg_control field. This allows to
propagate __user annotations nicely through this struct.
Store optval in msg_control_user to properly record and propagate the
memory space annotation of this pointer.
Note that msg_control_is_user is set to true, so the key invariant, i.e.,
use msg_control_user if and only if msg_control_is_user is true, holds.
The msghdr is further used in the six alternative put_cmsg() calls, with
msg_control_is_user being true, put_cmsg() picks msg_control_user
preserving the __user annotation and passes that properly to
copy_to_user().
No functional change. No change in object code.
Signed-off-by: Lukas Bulwahn
---
Christoph, please review and ack.
David, Alexey, Hideaki-san, Jakub,
please pick this minor non-urgent clean-up patch.
net/ipv6/ipv6_sockglue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 43a894bf9a1b..a6804a7e34c1 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1148,7 +1148,7 @@ static int do_ipv6_getsockopt(struct sock *sk, int level,
int optname,
if (sk->sk_type != SOCK_STREAM)
return -ENOPROTOOPT;
- msg.msg_control = optval;
+ msg.msg_control_user = optval;
msg.msg_controllen = len;
msg.msg_flags = flags;
msg.msg_control_is_user = true;
--
2.17.1
[PATCH] drm/dev: Fix NULL pointer dereference in drm_minor_alloc
KASAN: null-ptr-deref in range [0x0030-0x0037]
CPU: 0 PID: 18491 Comm: syz-executor.0 Tainted: G C 5.10.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1
04/01/2014
RIP: 0010:kobject_put+0x2f/0x140
Call Trace:
put_device+0x20/0x40
drm_minor_alloc_release+0x60/0xe0 [drm]
drm_managed_release+0x1b6/0x440 [drm]
drm_dev_init+0x50b/0x8e0 [drm]
__devm_drm_dev_alloc+0x50/0x160 [drm]
vgem_init+0x15c/0x1000 [vgem]
do_one_initcall+0x149/0x7e0
do_init_module+0x1ef/0x700
load_module+0x3467/0x4140
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
kfree(minor->kdev) in put_device would raise a null-ptr-deref bug when
minor->kdev is null or error pointer. So do check before put_device in
drm_minor_alloc_release and prohibit minor->kdev becoming an error pointer.
Fixes: f96306f9892b ("drm: manage drm_minor cleanup with drmm_")
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/drm_drv.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index cd162d406..c253d3cd4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -100,7 +100,8 @@ static void drm_minor_alloc_release(struct drm_device *dev,
void *data)
WARN_ON(dev != minor->dev);
- put_device(minor->kdev);
+ if (minor->kdev)
+ put_device(minor->kdev);
spin_lock_irqsave(_minor_lock, flags);
idr_remove(_minors_idr, minor->index);
@@ -140,8 +141,11 @@ static int drm_minor_alloc(struct drm_device *dev,
unsigned int type)
return r;
minor->kdev = drm_sysfs_minor_alloc(minor);
- if (IS_ERR(minor->kdev))
- return PTR_ERR(minor->kdev);
+ if (IS_ERR(minor->kdev)) {
+ r = PTR_ERR(minor->kdev);
+ minor->kdev = NULL;
+ return r;
+ }
*drm_minor_get_slot(dev, type) = minor;
return 0;
--
2.23.0
[PATCH] crypto: sa2ul - fix reference leak in sa_ul_probe()
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/crypto/sa2ul.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index eda93fab9..39d56ab12 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -2345,7 +2345,7 @@ static int sa_ul_probe(struct platform_device *pdev)
dev_set_drvdata(sa_k3_dev, dev_data);
pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
dev_err(>dev, "%s: failed to get sync: %d\n", __func__,
ret);
--
2.23.0
[PATCH] dmaengine: usb-mac: fix reference leak in usb_dmac_probe
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 0c1c8ff32fa2 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller
(USB-DMAC) driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/sh/usb-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 8f7ceb698..2a6c8fd88 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -796,7 +796,7 @@ static int usb_dmac_probe(struct platform_device *pdev)
/* Enable runtime PM and initialize the device. */
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0) {
dev_err(>dev, "runtime PM get sync failed (%d)\n", ret);
goto error_pm;
--
2.23.0
[PATCH] dmaengine: zynqmp_dma: fix reference leak in zynqmp_dma_alloc_chan_resources
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 64c6f7da8c2c ("dmaengine: zynqmp_dma: Add runtime pm support")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/xilinx/zynqmp_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index d8419565b..5fecf5aa6 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -468,7 +468,7 @@ static int zynqmp_dma_alloc_chan_resources(struct dma_chan
*dchan)
struct zynqmp_dma_desc_sw *desc;
int i, ret;
- ret = pm_runtime_get_sync(chan->dev);
+ ret = pm_runtime_resume_and_get(chan->dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH] drm: bridge: cdns-mhdp8546: fix reference leak in cdns_mhdp_probe
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP
bridge")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0c65610e..3ee515d21 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2369,7 +2369,7 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
clk_prepare_enable(clk);
pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
dev_err(dev, "pm_runtime_get_sync failed\n");
pm_runtime_disable(dev);
--
2.23.0
[PATCH] hwrng: exynos - fix reference leak in exynos_trng_probe
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 6cd225cc5d8a ("hwrng: exynos - add Samsung Exynos True RNG driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/char/hw_random/exynos-trng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/exynos-trng.c
b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8d..666246bc8 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -132,7 +132,7 @@ static int exynos_trng_probe(struct platform_device *pdev)
return PTR_ERR(trng->mem);
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0) {
dev_err(>dev, "Could not get runtime PM.\n");
goto err_pm_get;
--
2.23.0
[PATCH] drm: rcar-du: fix reference leak in amdgpu_debugfs_gfxoff_read
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 2d125b8b1..05de69a97 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1096,7 +1096,7 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file *f,
char __user *buf,
if (size & 0x3 || *pos & 0x3)
return -EINVAL;
- r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+ r = pm_runtime_resume_and_get(adev_to_drm(adev)->dev);
if (r < 0)
return r;
--
2.23.0
[PATCH] dmaengine: rcar-dmac: fix reference leak in rcar_dmac_probe
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 87244fe5abdf ("dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA
Controller (DMAC) driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index a57705356..991a7b5da 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1874,7 +1874,7 @@ static int rcar_dmac_probe(struct platform_device *pdev)
/* Enable runtime PM and initialize the device. */
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0) {
dev_err(>dev, "runtime PM get sync failed (%d)\n", ret);
return ret;
--
2.23.0
[PATCH] drm/bridge: cdns: fix reference leak in cdns_dsi_transfer
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 76373e31d..b31281f76 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -1028,7 +1028,7 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host
*host,
struct mipi_dsi_packet packet;
int ret, i, tx_len, rx_len;
- ret = pm_runtime_get_sync(host->dev);
+ ret = pm_runtime_resume_and_get(host->dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH] gpio: zynq: fix reference leak in zynq_gpio functions
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: c2df3de0d07e ("gpio: zynq: properly support runtime PM for GPIO used as
interrupts")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpio/gpio-zynq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 0b5a17ab9..3521c1dc3 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -574,7 +574,7 @@ static int zynq_gpio_irq_reqres(struct irq_data *d)
struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
int ret;
- ret = pm_runtime_get_sync(chip->parent);
+ ret = pm_runtime_resume_and_get(chip->parent);
if (ret < 0)
return ret;
@@ -942,7 +942,7 @@ static int zynq_gpio_probe(struct platform_device *pdev)
pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0)
goto err_pm_dis;
--
2.23.0
[PATCH 2/2] iio: adc: ad7298: check regulator for null in ad7298_get_ref_voltage()
'st->ext_ref' & 'st->reg' are both non-zero/non-null at the same time, so
logically the code isn't broken.
But it is more correct to check that 'st->reg' is non-null, since we make
sure that the regulator is NULL (in probe) in case one isn't defined.
Cc: Colin Ian King
Signed-off-by: Alexandru Ardelean
---
drivers/iio/adc/ad7298.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ad7298.c b/drivers/iio/adc/ad7298.c
index ecdb01bd5b2f..689ecd5dd563 100644
--- a/drivers/iio/adc/ad7298.c
+++ b/drivers/iio/adc/ad7298.c
@@ -214,7 +214,7 @@ static int ad7298_get_ref_voltage(struct ad7298_state *st)
{
int vref;
- if (st->ext_ref) {
+ if (st->reg) {
vref = regulator_get_voltage(st->reg);
if (vref < 0)
return vref;
--
2.27.0
[PATCH] drm/lima: fix reference leak in lima_pm_busy
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 50de2e9ebbc0 ("drm/lima: enable runtime pm")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/lima/lima_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index dc6df9e9a..f6e7a88a5 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -200,7 +200,7 @@ static int lima_pm_busy(struct lima_device *ldev)
int ret;
/* resume GPU if it has been suspended by runtime PM */
- ret = pm_runtime_get_sync(ldev->dev);
+ ret = pm_runtime_resume_and_get(ldev->dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH 1/2] iio: adc: ad7298: convert probe to device-managed functions
This change converts the probe of this driver to use device-managed
register functions, and a devm_add_action_or_reset() for the regulator
disable.
With this, the exit & error paths can be removed.
Another side-effect is that this should avoid some static-analyzer's check
with respect to a potential null dereference of the regulator. The null
dereference isn't likely to happen (under normal operation), so there isn't
a requirement to have this fixed/backported in other releases.
As a note: this is removing spi_set_drvdata() since there is no other
spi_get_drvdata() (or dev_get_drvdata()) call that need it.
Cc: Colin Ian King
Signed-off-by: Alexandru Ardelean
---
drivers/iio/adc/ad7298.c | 46 +---
1 file changed, 15 insertions(+), 31 deletions(-)
diff --git a/drivers/iio/adc/ad7298.c b/drivers/iio/adc/ad7298.c
index fa1047f74a1f..ecdb01bd5b2f 100644
--- a/drivers/iio/adc/ad7298.c
+++ b/drivers/iio/adc/ad7298.c
@@ -279,6 +279,13 @@ static const struct iio_info ad7298_info = {
.update_scan_mode = ad7298_update_scan_mode,
};
+static void ad7298_reg_disable(void *data)
+{
+ struct regulator *reg = data;
+
+ regulator_disable(reg);
+}
+
static int ad7298_probe(struct spi_device *spi)
{
struct ad7298_state *st;
@@ -306,9 +313,12 @@ static int ad7298_probe(struct spi_device *spi)
ret = regulator_enable(st->reg);
if (ret)
return ret;
- }
- spi_set_drvdata(spi, indio_dev);
+ ret = devm_add_action_or_reset(>dev, ad7298_reg_disable,
+ st->reg);
+ if (ret)
+ return ret;
+ }
st->spi = spi;
@@ -334,37 +344,12 @@ static int ad7298_probe(struct spi_device *spi)
spi_message_add_tail(>scan_single_xfer[1], >scan_single_msg);
spi_message_add_tail(>scan_single_xfer[2], >scan_single_msg);
- ret = iio_triggered_buffer_setup(indio_dev, NULL,
+ ret = devm_iio_triggered_buffer_setup(>dev, indio_dev, NULL,
_trigger_handler, NULL);
if (ret)
- goto error_disable_reg;
-
- ret = iio_device_register(indio_dev);
- if (ret)
- goto error_cleanup_ring;
-
- return 0;
-
-error_cleanup_ring:
- iio_triggered_buffer_cleanup(indio_dev);
-error_disable_reg:
- if (st->ext_ref)
- regulator_disable(st->reg);
-
- return ret;
-}
-
-static int ad7298_remove(struct spi_device *spi)
-{
- struct iio_dev *indio_dev = spi_get_drvdata(spi);
- struct ad7298_state *st = iio_priv(indio_dev);
-
- iio_device_unregister(indio_dev);
- iio_triggered_buffer_cleanup(indio_dev);
- if (st->ext_ref)
- regulator_disable(st->reg);
+ return ret;
- return 0;
+ return devm_iio_device_register(>dev, indio_dev);
}
static const struct spi_device_id ad7298_id[] = {
@@ -378,7 +363,6 @@ static struct spi_driver ad7298_driver = {
.name = "ad7298",
},
.probe = ad7298_probe,
- .remove = ad7298_remove,
.id_table = ad7298_id,
};
module_spi_driver(ad7298_driver);
--
2.27.0
[PATCH] drm: rcar-du: fix reference leak in rcar_cmm_enable
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index c578095b0..382d53f8a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -122,7 +122,7 @@ int rcar_cmm_enable(struct platform_device *pdev)
{
int ret;
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH] dmaengine: sprd: fix reference leak in sprd_dma_probe and sprd_dma_remove
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/sprd-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 0ef5ca81b..65dde392f 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -1203,7 +1203,7 @@ static int sprd_dma_probe(struct platform_device *pdev)
pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0)
goto err_rpm;
@@ -1238,7 +1238,7 @@ static int sprd_dma_remove(struct platform_device *pdev)
struct sprd_dma_chn *c, *cn;
int ret;
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH] drm/panfrost: fix reference leak in panfrost_job_hw_submit
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 30e7b7196..04cf3bb67 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -147,7 +147,7 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
panfrost_devfreq_record_busy(>pfdevfreq);
- ret = pm_runtime_get_sync(pfdev->dev);
+ ret = pm_runtime_resume_and_get(pfdev->dev);
if (ret < 0)
return;
--
2.23.0
[PATCH 0/3] dmaengine: stm32: fix reference leak
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. Use pm_runtime_resume_and_get to fix it. Qinglang Miao (3): dmaengine: stm32-dma: fix reference leak in stm32_dma dmaengine: stm32-dmamux: fix reference leak in stm32_dmamux dmaengine: stm32-mdma: fix reference leak in stm32-mdma drivers/dma/stm32-dma.c| 4 ++-- drivers/dma/stm32-dmamux.c | 6 +++--- drivers/dma/stm32-mdma.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.23.0
[PATCH 1/3] dmaengine: stm32-dma: fix reference leak in stm32_dma
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: 05f8740a0e6f ("dmaengine: stm32-dma: add suspend/resume power management
support")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/stm32-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index d0055d2f0..1150aa90e 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -1187,7 +1187,7 @@ static int stm32_dma_alloc_chan_resources(struct dma_chan
*c)
chan->config_init = false;
- ret = pm_runtime_get_sync(dmadev->ddev.dev);
+ ret = pm_runtime_resume_and_get(dmadev->ddev.dev);
if (ret < 0)
return ret;
@@ -1455,7 +1455,7 @@ static int stm32_dma_suspend(struct device *dev)
struct stm32_dma_device *dmadev = dev_get_drvdata(dev);
int id, ret, scr;
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
--
2.23.0
[PATCH 2/3] dmaengine: stm32-dmamux: fix reference leak in stm32_dmamux
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the reference
leak by replacing it with new funtion.
[0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
usage counter")
Fixes: f65c2e14b096 ("dmaengine: stm32-dmamux: add suspend/resume power
management support")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/dma/stm32-dmamux.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
index a10ccd964..bddd3b23f 100644
--- a/drivers/dma/stm32-dmamux.c
+++ b/drivers/dma/stm32-dmamux.c
@@ -137,7 +137,7 @@ static void *stm32_dmamux_route_allocate(struct
of_phandle_args *dma_spec,
/* Set dma request */
spin_lock_irqsave(>lock, flags);
- ret = pm_runtime_get_sync(>dev);
+ ret = pm_runtime_resume_and_get(>dev);
if (ret < 0) {
spin_unlock_irqrestore(>lock, flags);
goto error;
@@ -336,7 +336,7 @@ static int stm32_dmamux_suspend(struct device *dev)
struct stm32_dmamux_data *stm32_dmamux = platform_get_drvdata(pdev);
int i, ret;
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
@@ -361,7 +361,7 @@ static int stm32_dmamux_resume(struct device *dev)
if (ret < 0)
return ret;
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
--
2.23.0
