Re: [PATCH kernel] fs/io_ring: Fix lockdep warnings
On 01/12/2020 03:34, Pavel Begunkov wrote: On 30/11/2020 02:00, Alexey Kardashevskiy wrote: There are a few potential deadlocks reported by lockdep and triggered by syzkaller (a syscall fuzzer). These are reported as timer interrupts can execute softirq handlers and if we were executing certain bits of io_ring, a deadlock can occur. This fixes those bits by disabling soft interrupts. Jens already fixed that, thanks https://lore.kernel.org/io-uring/948d2d3b-5f36-034d-28e6-7490343a5...@kernel.dk/T/#t Oh good! I assumed it must be fixed somewhere but could not find it quickly in the lists. FYI, your email got into spam. Not good :-/ Wonder why... Can you please forward my mail in attachment for debugging (there should be nothing private, I guess)? spf should be alright, not sure what else I can do. Thanks, -- Alexey
Re: [GIT pull] locking/urgent for v5.10-rc6
On Tue, Dec 01, 2020 at 08:39:06AM +0100, Peter Zijlstra wrote: > On Mon, Nov 30, 2020 at 09:55:44AM -0800, Linus Torvalds wrote: > > > Yes, yes, I can very well imagine some hardware doing a "idle until > > you sense an interrupt, but don't actually take it". It's not > > _impossible_. But it's certainly not normal. > > A lot of hardware actually does that, including modern x86. But yes, not > nearly everything. So the thing is that (with exception of RCU-tiny), we need interrupts disabled when coming out of idle to prod RCU back into action. So even if an architecture needs to enable interrupts on idle, we need it disabled again when coming out. So we might as well have the arch idle routine then be: STI; HLT; CLI; because then architectures than can idle with interrupts disabled can avoid mucking about with the interrupt state entirely. Currently they (and this includes much of ARM) are effectively doing: wfi(); raw_local_irq_enable(); raw_local_irq_disable(); where a plain: wfi(), would be sufficient.
Re: [PATCH] bus: mhi: core: Fix error handling in mhi_register_controller()
On Tue, 1 Dec 2020 at 08:05, Dan Carpenter wrote:
>
> There are a few problems with the error handling in this function. They
> mostly center around the alloc_ordered_workqueue() allocation.
> 1) If that allocation fails or if the kcalloc() prior to it fails then
> it leads to a NULL dereference when we call
> destroy_workqueue(mhi_cntrl->hiprio_wq).
> 2) The error code is not set.
> 3) The "mhi_cntrl->mhi_cmd" allocation is not freed.
>
> The error handling was slightly confusing and I re-ordered it to be in
> the exact mirror/reverse order of how things were allocated. I changed
> the label names to say what the goto does instead of describing where
> the goto comes from.
>
> Fixes: 8f7039787687 ("bus: mhi: core: Move to using high priority workqueue")
> Signed-off-by: Dan Carpenter
Reviewed-by: Loic Poulain
[PATCH v13 10/10] secretmem: test: add basic selftest for memfd_secret(2)
From: Mike Rapoport
The test verifies that file descriptor created with memfd_secret does
not allow read/write operations, that secret memory mappings respect
RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and
ptrace() to the secret memory fail.
Signed-off-by: Mike Rapoport
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 3 +-
tools/testing/selftests/vm/memfd_secret.c | 298 ++
tools/testing/selftests/vm/run_vmtests| 17 ++
4 files changed, 318 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/vm/memfd_secret.c
diff --git a/tools/testing/selftests/vm/.gitignore
b/tools/testing/selftests/vm/.gitignore
index 9a35c3f6a557..c8deddc81e7a 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -21,4 +21,5 @@ va_128TBswitch
map_fixed_noreplace
write_to_hugetlbfs
hmm-tests
+memfd_secret
local_config.*
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index 62fb15f286ee..9ab98946fbf2 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -34,6 +34,7 @@ TEST_GEN_FILES += khugepaged
TEST_GEN_FILES += map_fixed_noreplace
TEST_GEN_FILES += map_hugetlb
TEST_GEN_FILES += map_populate
+TEST_GEN_FILES += memfd_secret
TEST_GEN_FILES += mlock-random-test
TEST_GEN_FILES += mlock2-tests
TEST_GEN_FILES += mremap_dontunmap
@@ -129,7 +130,7 @@ warn_32bit_failure:
endif
endif
-$(OUTPUT)/mlock-random-test: LDLIBS += -lcap
+$(OUTPUT)/mlock-random-test $(OUTPUT)/memfd_secret: LDLIBS += -lcap
$(OUTPUT)/gup_test: ../../../../mm/gup_test.h
diff --git a/tools/testing/selftests/vm/memfd_secret.c
b/tools/testing/selftests/vm/memfd_secret.c
new file mode 100644
index ..79578dfd13e6
--- /dev/null
+++ b/tools/testing/selftests/vm/memfd_secret.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright IBM Corporation, 2020
+ *
+ * Author: Mike Rapoport
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "../kselftest.h"
+
+#define fail(fmt, ...) ksft_test_result_fail(fmt, ##__VA_ARGS__)
+#define pass(fmt, ...) ksft_test_result_pass(fmt, ##__VA_ARGS__)
+#define skip(fmt, ...) ksft_test_result_skip(fmt, ##__VA_ARGS__)
+
+#ifdef __NR_memfd_secret
+
+#include
+
+#define PATTERN0x55
+
+static const int prot = PROT_READ | PROT_WRITE;
+static const int mode = MAP_SHARED;
+
+static unsigned long page_size;
+static unsigned long mlock_limit_cur;
+static unsigned long mlock_limit_max;
+
+static int memfd_secret(unsigned long flags)
+{
+ return syscall(__NR_memfd_secret, flags);
+}
+
+static void test_file_apis(int fd)
+{
+ char buf[64];
+
+ if ((read(fd, buf, sizeof(buf)) >= 0) ||
+ (write(fd, buf, sizeof(buf)) >= 0) ||
+ (pread(fd, buf, sizeof(buf), 0) >= 0) ||
+ (pwrite(fd, buf, sizeof(buf), 0) >= 0))
+ fail("unexpected file IO\n");
+ else
+ pass("file IO is blocked as expected\n");
+}
+
+static void test_mlock_limit(int fd)
+{
+ size_t len;
+ char *mem;
+
+ len = mlock_limit_cur;
+ mem = mmap(NULL, len, prot, mode, fd, 0);
+ if (mem == MAP_FAILED) {
+ fail("unable to mmap secret memory\n");
+ return;
+ }
+ munmap(mem, len);
+
+ len = mlock_limit_max * 2;
+ mem = mmap(NULL, len, prot, mode, fd, 0);
+ if (mem != MAP_FAILED) {
+ fail("unexpected mlock limit violation\n");
+ munmap(mem, len);
+ return;
+ }
+
+ pass("mlock limit is respected\n");
+}
+
+static void try_process_vm_read(int fd, int pipefd[2])
+{
+ struct iovec liov, riov;
+ char buf[64];
+ char *mem;
+
+ if (read(pipefd[0], , sizeof(mem)) < 0) {
+ fail("pipe write: %s\n", strerror(errno));
+ exit(KSFT_FAIL);
+ }
+
+ liov.iov_len = riov.iov_len = sizeof(buf);
+ liov.iov_base = buf;
+ riov.iov_base = mem;
+
+ if (process_vm_readv(getppid(), , 1, , 1, 0) < 0) {
+ if (errno == ENOSYS)
+ exit(KSFT_SKIP);
+ exit(KSFT_PASS);
+ }
+
+ exit(KSFT_FAIL);
+}
+
+static void try_ptrace(int fd, int pipefd[2])
+{
+ pid_t ppid = getppid();
+ int status;
+ char *mem;
+ long ret;
+
+ if (read(pipefd[0], , sizeof(mem)) < 0) {
+ perror("pipe write");
+ exit(KSFT_FAIL);
+ }
+
+ ret = ptrace(PTRACE_ATTACH, ppid, 0, 0);
+ if (ret) {
+ perror("ptrace_attach");
+ exit(KSFT_FAIL);
+ }
+
+ ret = waitpid(ppid, , WUNTRACED);
+ if ((ret != ppid) || !(WIFSTOPPED(status))) {
+ fprintf(stderr, "weird
Re: [GIT pull] locking/urgent for v5.10-rc6
Hi Peter, Peter Zijlstra writes: > On Mon, Nov 30, 2020 at 01:52:11PM +0100, Peter Zijlstra wrote: >> On Mon, Nov 30, 2020 at 01:31:33PM +0100, Sven Schnelle wrote: >> > [0.670280] [ cut here ] >> > [0.670288] WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:1054 >> > rcu_irq_enter+0x7e/0xa8 >> > [0.670293] Modules linked in: >> > [0.670299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW >> > 5.10.0-rc6 #2263 >> > [0.670304] Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0) >> > [0.670309] Krnl PSW : 0404d0018000 00d8a8da >> > (rcu_irq_enter+0x82/0xa8) >> > [0.670318]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 >> > PM:0 RI:0 EA:3 >> > [0.670325] Krnl GPRS: 8002 >> > 0001 0101fcee >> > [0.670331] >> > >> > [0.670337]03e00029ff48 >> > 017212d8 0001 >> > [0.670343]05ba0100 000324bb >> > 03e00029fe40 03e00029fe10 >> > >> > [0.670358] Krnl Code: 00d8a8ca: ec180013017ecij >> > %r1,1,8,00d8a8f0 >> > [0.670358]00d8a8d0: ecb80005007ecij >> > %r11,0,8,00d8a8da >> > [0.670358] #00d8a8d6: af00mc >> > 0,0 >> > [0.670358] >00d8a8da: ebbff0a4lmg >> > %r11,%r15,160(%r15) >> > [0.670358]00d8a8e0: c0f4ff68brcl >> > 15,00d8a7b0 >> > [0.670358]00d8a8e6: c0e538c1brasl >> > %r14,00d91a68 >> > [0.670358]00d8a8ec: a7f4ffdcbrc >> > 15,00d8a8a4 >> > [0.670358]00d8a8f0: c0e538bcbrasl >> > %r14,00d91a68 >> > [0.670392] Call Trace: >> > [0.670396] [<00d8a8da>] rcu_irq_enter+0x82/0xa8 >> > [0.670401] [<00157f9a>] irq_enter+0x22/0x30 >> > [0.670404] [<0010e51c>] do_IRQ+0x64/0xd0 >> > [0.670408] [<00d9a65a>] ext_int_handler+0x18e/0x194 >> > [0.670412] [<00d9a6a0>] psw_idle+0x40/0x48 >> > [0.670416] ([<00104202>] enabled_wait+0x22/0xf0) >> > [0.670419] [<001046e2>] arch_cpu_idle+0x22/0x38 >> > [0.670423] [<00d986cc>] default_idle_call+0x74/0xd8 >> > [0.670427] [<0019a94a>] do_idle+0xf2/0x1b0 >> > [0.670431] [<0019ac7e>] cpu_startup_entry+0x36/0x40 >> > [0.670435] [<00118b9a>] smp_start_secondary+0x82/0x88 >> >> But but but... >> >> do_idle() # IRQs on >> local_irq_disable(); # IRQs off >> defaul_idle_call() # IRQs off > lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on >> arch_cpu_idle()# IRQs off >> enabled_wait() # IRQs off >>raw_local_save() # still off >>psw_idle()# very much off >> ext_int_handler # get an interrupt ?!?! > rcu_irq_enter() # lockdep thinks IRQs are on <- FAIL > > > I can't much read s390 assembler, but ext_int_handler() has a > TRACE_IRQS_OFF, which would be sufficient to re-align the lockdep state > with the actual state, but there's some condition before it, what's that > test and is that right? That test was introduced to only track changes in IRQ state because of recursion problems in lockdep. This now seems to no longer work. We propably could remove that as lockdep now can handle recursion much better with all the recent changes, but given that we're already at -rc6, i don't want to touch entry.S code because of a debugging feature.
[PATCH v13 08/10] PM: hibernate: disable when there are active secretmem users
From: Mike Rapoport
It is unsafe to allow saving of secretmem areas to the hibernation snapshot
as they would be visible after the resume and this essentially will defeat
the purpose of secret memory mappings.
Prevent hibernation whenever there are active secret memory users.
Signed-off-by: Mike Rapoport
---
include/linux/secretmem.h | 6 ++
kernel/power/hibernate.c | 5 -
mm/secretmem.c| 15 +++
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 70e7db9f94fe..907a6734059c 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -6,6 +6,7 @@
bool vma_is_secretmem(struct vm_area_struct *vma);
bool page_is_secretmem(struct page *page);
+bool secretmem_active(void);
#else
@@ -19,6 +20,11 @@ static inline bool page_is_secretmem(struct page *page)
return false;
}
+static inline bool secretmem_active(void)
+{
+ return false;
+}
+
#endif /* CONFIG_SECRETMEM */
#endif /* _LINUX_SECRETMEM_H */
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index da0b41914177..559acef3fddb 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "power.h"
@@ -81,7 +82,9 @@ void hibernate_release(void)
bool hibernation_available(void)
{
- return nohibernate == 0 && !security_locked_down(LOCKDOWN_HIBERNATION);
+ return nohibernate == 0 &&
+ !security_locked_down(LOCKDOWN_HIBERNATION) &&
+ !secretmem_active();
}
/**
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 5e3e5102ad4c..2cf5cc79418b 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -45,6 +45,13 @@ struct secretmem_ctx {
static struct cma *secretmem_cma;
+static atomic_t secretmem_users;
+
+bool secretmem_active(void)
+{
+ return !!atomic_read(_users);
+}
+
static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
{
int err;
@@ -179,6 +186,12 @@ static const struct vm_operations_struct secretmem_vm_ops
= {
.fault = secretmem_fault,
};
+static int secretmem_release(struct inode *inode, struct file *file)
+{
+ atomic_dec(_users);
+ return 0;
+}
+
static int secretmem_mmap(struct file *file, struct vm_area_struct *vma)
{
unsigned long len = vma->vm_end - vma->vm_start;
@@ -201,6 +214,7 @@ bool vma_is_secretmem(struct vm_area_struct *vma)
}
static const struct file_operations secretmem_fops = {
+ .release= secretmem_release,
.mmap = secretmem_mmap,
};
@@ -318,6 +332,7 @@ SYSCALL_DEFINE1(memfd_secret, unsigned long, flags)
file->f_flags |= O_LARGEFILE;
fd_install(fd, file);
+ atomic_inc(_users);
return fd;
err_put_fd:
--
2.28.0
[PATCH v13 09/10] arch, mm: wire up memfd_secret system call were relevant
From: Mike Rapoport Wire up memfd_secret system call on architectures that define ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86. Signed-off-by: Mike Rapoport Acked-by: Palmer Dabbelt Acked-by: Arnd Bergmann --- arch/arm64/include/uapi/asm/unistd.h | 1 + arch/riscv/include/asm/unistd.h| 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 6 +- mm/secretmem.c | 3 +++ scripts/checksyscalls.sh | 4 8 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h index f83a70e07df8..ce2ee8f1e361 100644 --- a/arch/arm64/include/uapi/asm/unistd.h +++ b/arch/arm64/include/uapi/asm/unistd.h @@ -20,5 +20,6 @@ #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 +#define __ARCH_WANT_MEMFD_SECRET #include diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h index 977ee6181dab..6c316093a1e5 100644 --- a/arch/riscv/include/asm/unistd.h +++ b/arch/riscv/include/asm/unistd.h @@ -9,6 +9,7 @@ */ #define __ARCH_WANT_SYS_CLONE +#define __ARCH_WANT_MEMFD_SECRET #include diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index c52ab1c4a755..109e6681b8fa 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -446,3 +446,4 @@ 439i386faccessat2 sys_faccessat2 440i386process_madvise sys_process_madvise 441i386watch_mount sys_watch_mount +442i386memfd_secretsys_memfd_secret diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index f3270a9ef467..742cf17d7725 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -363,6 +363,7 @@ 439common faccessat2 sys_faccessat2 440common process_madvise sys_process_madvise 441common watch_mount sys_watch_mount +442common memfd_secretsys_memfd_secret # # Due to a historical design error, certain syscalls are numbered differently diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 6d55324363ab..f9d93fbf9b69 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -1010,6 +1010,7 @@ asmlinkage long sys_pidfd_send_signal(int pidfd, int sig, asmlinkage long sys_pidfd_getfd(int pidfd, int fd, unsigned int flags); asmlinkage long sys_watch_mount(int dfd, const char __user *path, unsigned int at_flags, int watch_fd, int watch_id); +asmlinkage long sys_memfd_secret(unsigned long flags); /* * Architecture-specific system calls diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 5df46517260e..51151888f330 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -861,9 +861,13 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2) __SYSCALL(__NR_process_madvise, sys_process_madvise) #define __NR_watch_mount 441 __SYSCALL(__NR_watch_mount, sys_watch_mount) +#ifdef __ARCH_WANT_MEMFD_SECRET +#define __NR_memfd_secret 442 +__SYSCALL(__NR_memfd_secret, sys_memfd_secret) +#endif #undef __NR_syscalls -#define __NR_syscalls 442 +#define __NR_syscalls 443 /* * 32 bit systems traditionally used different diff --git a/mm/secretmem.c b/mm/secretmem.c index 2cf5cc79418b..ecd7a586af8e 100644 --- a/mm/secretmem.c +++ b/mm/secretmem.c @@ -415,6 +415,9 @@ static int __init secretmem_setup(char *str) unsigned long reserved_size; int err; + if (!can_set_direct_map()) + return 0; + reserved_size = memparse(str, NULL); if (!reserved_size) return 0; diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh index a18b47695f55..b7609958ee36 100755 --- a/scripts/checksyscalls.sh +++ b/scripts/checksyscalls.sh @@ -40,6 +40,10 @@ cat << EOF #define __IGNORE_setrlimit /* setrlimit */ #endif +#ifndef __ARCH_WANT_MEMFD_SECRET +#define __IGNORE_memfd_secret +#endif + /* Missing flags argument */ #define __IGNORE_renameat /* renameat2 */ -- 2.28.0
[PATCH v13 07/10] secretmem: add memcg accounting
From: Mike Rapoport
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
Acked-by: Roman Gushchin
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 249cf489f5df..cf7f1dc9f4b8 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "internal.h"
#define CREATE_TRACE_POINTS
@@ -844,7 +845,7 @@ static noinline int __add_to_page_cache_locked(struct page
*page,
page->mapping = mapping;
page->index = offset;
- if (!huge) {
+ if (!huge && !page_is_secretmem(page)) {
error = mem_cgroup_charge(page, current->mm, gfp);
if (error)
goto error;
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 52a900a135a5..5e3e5102ad4c 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,32 @@ struct secretmem_ctx {
static struct cma *secretmem_cma;
+static int secretmem_account_pages(struct page *page, gfp_t gfp, int order)
+{
+ int err;
+
+ err = memcg_kmem_charge_page(page, gfp, order);
+ if (err)
+ return err;
+
+ /*
+* seceremem caches are unreclaimable kernel allocations, so treat
+* them as unreclaimable slab memory for VM statistics purposes
+*/
+ mod_lruvec_page_state(page, NR_SLAB_UNRECLAIMABLE_B,
+ PAGE_SIZE << order);
+
+ return 0;
+}
+
+static void secretmem_unaccount_pages(struct page *page, int order)
+{
+
+ mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
+ -PAGE_SIZE << order);
+ memcg_kmem_uncharge_page(page, order);
+}
+
static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
{
unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
@@ -56,10 +83,14 @@ static int secretmem_pool_increase(struct secretmem_ctx
*ctx, gfp_t gfp)
if (!page)
return -ENOMEM;
- err = set_direct_map_invalid_noflush(page, nr_pages);
+ err = secretmem_account_pages(page, gfp, PMD_PAGE_ORDER);
if (err)
goto err_cma_release;
+ err = set_direct_map_invalid_noflush(page, nr_pages);
+ if (err)
+ goto err_memcg_uncharge;
+
addr = (unsigned long)page_address(page);
err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
if (err)
@@ -76,6 +107,8 @@ static int secretmem_pool_increase(struct secretmem_ctx
*ctx, gfp_t gfp)
* won't fail
*/
set_direct_map_default_noflush(page, nr_pages);
+err_memcg_uncharge:
+ secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
err_cma_release:
cma_release(secretmem_cma, page, nr_pages);
return err;
@@ -302,6 +335,7 @@ static void secretmem_cleanup_chunk(struct gen_pool *pool,
int i;
set_direct_map_default_noflush(page, nr_pages);
+ secretmem_unaccount_pages(page, PMD_PAGE_ORDER);
for (i = 0; i < nr_pages; i++)
clear_highpage(page + i);
--
2.28.0
Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway
On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap wrote: > > On 11/30/20 12:43 AM, Dmitry Vyukov wrote: > > On Mon, Nov 30, 2020 at 5:29 AM Randy Dunlap wrote: > >> > >> On 11/27/20 4:32 AM, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following issue on: > >>> > >>> HEAD commit:418baf2c Linux 5.10-rc5 > >>> git tree: upstream > >>> console output: https://syzkaller.appspot.com/x/log.txt?x=171555b950 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=b81aff78c272da44 > >>> dashboard link: > >>> https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff > >>> compiler: gcc (GCC) 10.1.0-syz 20200507 > >>> > >>> Unfortunately, I don't have any reproducer for this issue yet. > >>> > >>> IMPORTANT: if you fix the issue, please add the following tag to the > >>> commit: > >>> Reported-by: syzbot+3fd34060f26e76653...@syzkaller.appspotmail.com > >>> > >>> BFS-fs: bfs_fill_super(): loop5 is unclean, continuing > >>> BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 > >>> inodes, the real maximum is 511, mounting anyway > >>> BFS-fs: bfs_fill_super(): Last block not available on loop5: 120 > >>> BFS-fs: bfs_fill_super(): loop5 is unclean, continuing > >>> BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 > >>> inodes, the real maximum is 511, mounting anyway > >>> BFS-fs: bfs_fill_super(): Last block not available on loop5: 120 > >>> > >>> > >>> --- > >>> This report is generated by a bot. It may contain errors. > >>> See https://goo.gl/tpsmEJ for more information about syzbot. > >>> syzbot engineers can be reached at syzkal...@googlegroups.com. > >>> > >>> syzbot will keep track of this issue. See: > >>> https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > >>> > >> > >> Hi, > >> Can you provide the BFS image file that is being mounted? > >> (./file0 I think.) > >> > >> -- > >> ~Randy > > > > > > Hi Randy, > > > > I see this bug was reported with a reproducer: > > https://syzkaller.appspot.com/bug?id=a32ebd5db2f7c957b82cf54b97bdecf367bf0421 > > I assume it's a dup of this one. > > Sure, looks the same. > > > If you need the image itself, you can dump it to a file in the C > > reproducer inside of syz_mount_image before mount call. > > Yes, got that. > > What outcome or result are you looking for here? > Or what do you see as the problem? Hi Randy, "WARNING:" in kernel output is supposed to mean a kernel source bug. Presence of that kernel bug is what syzbot has reported. Note: the bug may be a misuse of the "WARNING:" for invalid user inputs in output as well :)
[PATCH v13 04/10] set_memory: allow querying whether set_direct_map_*() is actually enabled
From: Mike Rapoport
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush() and set_direct_map_default_noflush() have
any effect.
Extend set_memory API with can_set_direct_map() function that allows
checking if calling set_direct_map_*() will actually change the page table,
replace several occurrences of open coded checks in arm64 with the new
function and provide a generic stub for architectures that always modify
page tables upon calls to set_direct_map APIs.
Signed-off-by: Mike Rapoport
Reviewed-by: Catalin Marinas
Reviewed-by: David Hildenbrand
---
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/cacheflush.h | 6 --
arch/arm64/include/asm/set_memory.h | 17 +
arch/arm64/kernel/machine_kexec.c | 1 +
arch/arm64/mm/mmu.c | 6 +++---
arch/arm64/mm/pageattr.c| 13 +
include/linux/set_memory.h | 12
7 files changed, 42 insertions(+), 14 deletions(-)
create mode 100644 arch/arm64/include/asm/set_memory.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index ff9cbb631212..4306136ef329 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,5 +4,4 @@ generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += qrwlock.h
generic-y += qspinlock.h
-generic-y += set_memory.h
generic-y += user.h
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index d3598419a284..b1bdf83a73db 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -136,12 +136,6 @@ static __always_inline void __flush_icache_all(void)
dsb(ish);
}
-int set_memory_valid(unsigned long addr, int numpages, int enable);
-
-int set_direct_map_invalid_noflush(struct page *page, int numpages);
-int set_direct_map_default_noflush(struct page *page, int numpages);
-bool kernel_page_present(struct page *page);
-
#include
#endif /* __ASM_CACHEFLUSH_H */
diff --git a/arch/arm64/include/asm/set_memory.h
b/arch/arm64/include/asm/set_memory.h
new file mode 100644
index ..ecb6b0f449ab
--- /dev/null
+++ b/arch/arm64/include/asm/set_memory.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _ASM_ARM64_SET_MEMORY_H
+#define _ASM_ARM64_SET_MEMORY_H
+
+#include
+
+bool can_set_direct_map(void);
+#define can_set_direct_map can_set_direct_map
+
+int set_memory_valid(unsigned long addr, int numpages, int enable);
+
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
+bool kernel_page_present(struct page *page);
+
+#endif /* _ASM_ARM64_SET_MEMORY_H */
diff --git a/arch/arm64/kernel/machine_kexec.c
b/arch/arm64/kernel/machine_kexec.c
index a0b144cfaea7..0cbc50c4fa5a 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 86be6d1a78ab..aa5ec08cb902 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -477,7 +478,7 @@ static void __init map_mem(pgd_t *pgdp)
int flags = 0;
u64 i;
- if (rodata_full || debug_pagealloc_enabled())
+ if (can_set_direct_map())
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
/*
@@ -1453,8 +1454,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
* KFENCE requires linear map to be mapped at page granularity, so that
* it is possible to protect/unprotect single pages in the KFENCE pool.
*/
- if (rodata_full || debug_pagealloc_enabled() ||
- IS_ENABLED(CONFIG_KFENCE))
+ if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE))
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index b53ef37bf95a..d505172265b0 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -19,6 +19,11 @@ struct page_change_data {
bool rodata_full __ro_after_init =
IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED);
+bool can_set_direct_map(void)
+{
+ return rodata_full || debug_pagealloc_enabled();
+}
+
static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
{
struct page_change_data *cdata = data;
@@ -156,7 +161,7 @@ int set_direct_map_invalid_noflush(struct page *page, int
numpages)
};
unsigned long size = PAGE_SIZE * numpages;
- if (!debug_pagealloc_enabled() && !rodata_full)
+ if
[PATCH v13 06/10] secretmem: use PMD-size pages to amortize direct map fragmentation
From: Mike Rapoport
Removing a PAGE_SIZE page from the direct map every time such page is
allocated for a secret memory mapping will cause severe fragmentation of
the direct map. This fragmentation can be reduced by using PMD-size pages
as a pool for small pages for secret memory mappings.
Add a gen_pool per secretmem inode and lazily populate this pool with
PMD-size pages.
As pages allocated by secretmem become unmovable, use CMA to back large
page caches so that page allocator won't be surprised by failing attempt to
migrate these pages.
The CMA area used by secretmem is controlled by the "secretmem=" kernel
parameter. This allows explicit control over the memory available for
secretmem and provides upper hard limit for secretmem consumption.
Signed-off-by: Mike Rapoport
---
mm/Kconfig | 2 +
mm/secretmem.c | 152 ++---
2 files changed, 135 insertions(+), 19 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index d8d170fa5210..e0e789398421 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -886,5 +886,7 @@ config MAPPING_DIRTY_HELPERS
config SECRETMEM
def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
+ select GENERIC_ALLOCATOR
+ select CMA
endmenu
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 781aaaca8c70..52a900a135a5 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -7,12 +7,15 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -35,25 +38,80 @@
#define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK
struct secretmem_ctx {
+ struct gen_pool *pool;
unsigned int mode;
};
-static struct page *secretmem_alloc_page(gfp_t gfp)
+static struct cma *secretmem_cma;
+
+static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
{
+ unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
+ struct gen_pool *pool = ctx->pool;
+ unsigned long addr;
+ struct page *page;
+ int err;
+
+ page = cma_alloc(secretmem_cma, nr_pages, PMD_SIZE, gfp & __GFP_NOWARN);
+ if (!page)
+ return -ENOMEM;
+
+ err = set_direct_map_invalid_noflush(page, nr_pages);
+ if (err)
+ goto err_cma_release;
+
+ addr = (unsigned long)page_address(page);
+ err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
+ if (err)
+ goto err_set_direct_map;
+
+ flush_tlb_kernel_range(addr, addr + PMD_SIZE);
+
+ return 0;
+
+err_set_direct_map:
/*
-* FIXME: use a cache of large pages to reduce the direct map
-* fragmentation
+* If a split of PUD-size page was required, it already happened
+* when we marked the pages invalid which guarantees that this call
+* won't fail
*/
- return alloc_page(gfp);
+ set_direct_map_default_noflush(page, nr_pages);
+err_cma_release:
+ cma_release(secretmem_cma, page, nr_pages);
+ return err;
+}
+
+static struct page *secretmem_alloc_page(struct secretmem_ctx *ctx,
+gfp_t gfp)
+{
+ struct gen_pool *pool = ctx->pool;
+ unsigned long addr;
+ struct page *page;
+ int err;
+
+ if (gen_pool_avail(pool) < PAGE_SIZE) {
+ err = secretmem_pool_increase(ctx, gfp);
+ if (err)
+ return NULL;
+ }
+
+ addr = gen_pool_alloc(pool, PAGE_SIZE);
+ if (!addr)
+ return NULL;
+
+ page = virt_to_page(addr);
+ get_page(page);
+
+ return page;
}
static vm_fault_t secretmem_fault(struct vm_fault *vmf)
{
+ struct secretmem_ctx *ctx = vmf->vma->vm_file->private_data;
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
struct inode *inode = file_inode(vmf->vma->vm_file);
pgoff_t offset = vmf->pgoff;
vm_fault_t ret = 0;
- unsigned long addr;
struct page *page;
int err;
@@ -62,8 +120,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
page = find_get_page(mapping, offset);
if (!page) {
-
- page = secretmem_alloc_page(vmf->gfp_mask);
+ page = secretmem_alloc_page(ctx, vmf->gfp_mask);
if (!page)
return vmf_error(-ENOMEM);
@@ -71,14 +128,8 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
if (unlikely(err))
goto err_put_page;
- err = set_direct_map_invalid_noflush(page, 1);
- if (err)
- goto err_del_page_cache;
-
- addr = (unsigned long)page_address(page);
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
-
__SetPageUptodate(page);
+ set_page_private(page, (unsigned long)ctx);
ret = VM_FAULT_LOCKED;
}
@@ -86,8 +137,6 @@ static
[PATCH v13 05/10] mm: introduce memfd_secret system call to create "secret" memory areas
From: Mike Rapoport
Introduce "memfd_secret" system call with the ability to create memory
areas visible only in the context of the owning process and not mapped not
only to other processes but in the kernel page tables as well.
The user will create a file descriptor using the memfd_secret() system
call. The memory areas created by mmap() calls from this file descriptor
will be unmapped from the kernel direct map and they will be only mapped in
the page table of the owning mm.
The secret memory remains accessible in the process context using uaccess
primitives, but it is not accessible using direct/linear map addresses.
Functions in the follow_page()/get_user_page() family will refuse to return
a page that belongs to the secret memory area.
A page that was a part of the secret memory area is cleared when it is
freed.
The following example demonstrates creation of a secret mapping (error
handling is omitted):
fd = memfd_secret(0);
ftruncate(fd, MAP_SIZE);
ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Signed-off-by: Mike Rapoport
Acked-by: Hagen Paul Pfeifer
---
arch/x86/Kconfig | 2 +-
include/linux/secretmem.h | 24
include/uapi/linux/magic.h | 1 +
kernel/sys_ni.c| 2 +
mm/Kconfig | 3 +
mm/Makefile| 1 +
mm/gup.c | 10 ++
mm/secretmem.c | 273 +
8 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 include/linux/secretmem.h
create mode 100644 mm/secretmem.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 34d5fb82f674..7d781fea79c2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -41,7 +41,7 @@ config FORCE_DYNAMIC_FTRACE
in order to test the non static function tracing in the
generic code, as other architectures still use it. But we
only need to keep it around for x86_64. No need to keep it
-for x86_32. For x86_32, force DYNAMIC_FTRACE.
+for x86_32. For x86_32, force DYNAMIC_FTRACE.
#
# Arch settings
#
diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
new file mode 100644
index ..70e7db9f94fe
--- /dev/null
+++ b/include/linux/secretmem.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _LINUX_SECRETMEM_H
+#define _LINUX_SECRETMEM_H
+
+#ifdef CONFIG_SECRETMEM
+
+bool vma_is_secretmem(struct vm_area_struct *vma);
+bool page_is_secretmem(struct page *page);
+
+#else
+
+static inline bool vma_is_secretmem(struct vm_area_struct *vma)
+{
+ return false;
+}
+
+static inline bool page_is_secretmem(struct page *page)
+{
+ return false;
+}
+
+#endif /* CONFIG_SECRETMEM */
+
+#endif /* _LINUX_SECRETMEM_H */
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index f3956fc11de6..35687dcb1a42 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -97,5 +97,6 @@
#define DEVMEM_MAGIC 0x454d444d /* "DMEM" */
#define Z3FOLD_MAGIC 0x33
#define PPC_CMM_MAGIC 0xc7571590
+#define SECRETMEM_MAGIC0x5345434d /* "SECM" */
#endif /* __LINUX_MAGIC_H__ */
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 2dd6cbb8cabc..805fd7a668be 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -353,6 +353,8 @@ COND_SYSCALL(pkey_mprotect);
COND_SYSCALL(pkey_alloc);
COND_SYSCALL(pkey_free);
+/* memfd_secret */
+COND_SYSCALL(memfd_secret);
/*
* Architecture specific weak syscall entries.
diff --git a/mm/Kconfig b/mm/Kconfig
index c89c5444924b..d8d170fa5210 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -884,4 +884,7 @@ config ARCH_HAS_HUGEPD
config MAPPING_DIRTY_HELPERS
bool
+config SECRETMEM
+ def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
+
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index 6eeb4b29efb8..dfda14c48a75 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -121,3 +121,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
+obj-$(CONFIG_SECRETMEM) += secretmem.o
diff --git a/mm/gup.c b/mm/gup.c
index 5ec98de1e5de..71164fa83114 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -793,6 +794,9 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
struct follow_page_context ctx = { NULL };
struct page *page;
+ if (vma_is_secretmem(vma))
+ return NULL;
+
page = follow_page_mask(vma, address, foll_flags, );
if (ctx.pgmap)
put_dev_pagemap(ctx.pgmap);
@@ -923,6 +927,9 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
if (gup_flags & FOLL_ANON && !vma_is_anonymous(vma))
return -EFAULT;
+ if
[PATCH v13 02/10] mmap: make mlock_future_check() global
From: Mike Rapoport
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport
---
mm/internal.h | 3 +++
mm/mmap.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index c43ccdddb0f6..ae146a260b14 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct
vm_area_struct *vma)
extern void mlock_vma_page(struct page *page);
extern unsigned int munlock_vma_page(struct page *page);
+extern int mlock_future_check(struct mm_struct *mm, unsigned long flags,
+ unsigned long len);
+
/*
* Clear the page's PageMlocked(). This can be useful in a situation where
* we want to unconditionally remove a page from the pagecache -- e.g.,
diff --git a/mm/mmap.c b/mm/mmap.c
index 61f72b09d990..c481f088bd50 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned
long hint)
return hint;
}
-static inline int mlock_future_check(struct mm_struct *mm,
-unsigned long flags,
-unsigned long len)
+int mlock_future_check(struct mm_struct *mm, unsigned long flags,
+ unsigned long len)
{
unsigned long locked, lock_limit;
--
2.28.0
[PATCH v13 03/10] set_memory: allow set_direct_map_*_noflush() for multiple pages
From: Mike Rapoport
The underlying implementations of set_direct_map_invalid_noflush() and
set_direct_map_default_noflush() allow updating multiple contiguous pages
at once.
Add numpages parameter to set_direct_map_*_noflush() to expose this ability
with these APIs.
Signed-off-by: Mike Rapoport
Acked-by: Catalin Marinas # arm64
---
arch/arm64/include/asm/cacheflush.h | 4 ++--
arch/arm64/mm/pageattr.c| 10 ++
arch/riscv/include/asm/set_memory.h | 4 ++--
arch/riscv/mm/pageattr.c| 8
arch/x86/include/asm/set_memory.h | 4 ++--
arch/x86/mm/pat/set_memory.c| 8
include/linux/set_memory.h | 4 ++--
kernel/power/snapshot.c | 4 ++--
mm/vmalloc.c| 5 +++--
9 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index 45217f21f1fe..d3598419a284 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -138,8 +138,8 @@ static __always_inline void __flush_icache_all(void)
int set_memory_valid(unsigned long addr, int numpages, int enable);
-int set_direct_map_invalid_noflush(struct page *page);
-int set_direct_map_default_noflush(struct page *page);
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
bool kernel_page_present(struct page *page);
#include
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 92eccaf595c8..b53ef37bf95a 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -148,34 +148,36 @@ int set_memory_valid(unsigned long addr, int numpages,
int enable)
__pgprot(PTE_VALID));
}
-int set_direct_map_invalid_noflush(struct page *page)
+int set_direct_map_invalid_noflush(struct page *page, int numpages)
{
struct page_change_data data = {
.set_mask = __pgprot(0),
.clear_mask = __pgprot(PTE_VALID),
};
+ unsigned long size = PAGE_SIZE * numpages;
if (!debug_pagealloc_enabled() && !rodata_full)
return 0;
return apply_to_page_range(_mm,
(unsigned long)page_address(page),
- PAGE_SIZE, change_page_range, );
+ size, change_page_range, );
}
-int set_direct_map_default_noflush(struct page *page)
+int set_direct_map_default_noflush(struct page *page, int numpages)
{
struct page_change_data data = {
.set_mask = __pgprot(PTE_VALID | PTE_WRITE),
.clear_mask = __pgprot(PTE_RDONLY),
};
+ unsigned long size = PAGE_SIZE * numpages;
if (!debug_pagealloc_enabled() && !rodata_full)
return 0;
return apply_to_page_range(_mm,
(unsigned long)page_address(page),
- PAGE_SIZE, change_page_range, );
+ size, change_page_range, );
}
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/arch/riscv/include/asm/set_memory.h
b/arch/riscv/include/asm/set_memory.h
index d690b08dff2a..92b9bb26bf5e 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -22,8 +22,8 @@ static inline int set_memory_x(unsigned long addr, int
numpages) { return 0; }
static inline int set_memory_nx(unsigned long addr, int numpages) { return 0; }
#endif
-int set_direct_map_invalid_noflush(struct page *page);
-int set_direct_map_default_noflush(struct page *page);
+int set_direct_map_invalid_noflush(struct page *page, int numpages);
+int set_direct_map_default_noflush(struct page *page, int numpages);
bool kernel_page_present(struct page *page);
#endif /* __ASSEMBLY__ */
diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
index 87ba5a68bbb8..0454f2d052c4 100644
--- a/arch/riscv/mm/pageattr.c
+++ b/arch/riscv/mm/pageattr.c
@@ -150,11 +150,11 @@ int set_memory_nx(unsigned long addr, int numpages)
return __set_memory(addr, numpages, __pgprot(0), __pgprot(_PAGE_EXEC));
}
-int set_direct_map_invalid_noflush(struct page *page)
+int set_direct_map_invalid_noflush(struct page *page, int numpages)
{
int ret;
unsigned long start = (unsigned long)page_address(page);
- unsigned long end = start + PAGE_SIZE;
+ unsigned long end = start + PAGE_SIZE * numpages;
struct pageattr_masks masks = {
.set_mask = __pgprot(0),
.clear_mask = __pgprot(_PAGE_PRESENT)
@@ -167,11 +167,11 @@ int set_direct_map_invalid_noflush(struct page *page)
return ret;
}
-int set_direct_map_default_noflush(struct page *page)
+int set_direct_map_default_noflush(struct page *page, int numpages)
{
int ret;
unsigned long start = (unsigned
[PATCH] ARM: dts: omap3-gta04: fix twl4030-power settings
Things are wired up for powersaving, so lets use the corresponding
compatible and also update a deprecated property name.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/omap3-gta04.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index c8745bc800f7..cbe9ce739170 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -489,8 +489,8 @@
};
twl_power: power {
- compatible = "ti,twl4030-power";
- ti,use_poweroff;
+ compatible = "ti,twl4030-power-idle";
+ ti,system-power-controller;
};
};
};
--
2.20.1
[PATCH v13 00/10] mm: introduce memfd_secret system call to create "secret" memory areas
From: Mike Rapoport Hi, @Andrew, this is based on v5.10-rc2-mmotm-2020-11-07-21-40, I can rebase on current mmotm if you prefer. This is an implementation of "secret" mappings backed by a file descriptor. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will be present only in the page table of the owning mm. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, in the future the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloader.git that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. Hiding secret memory mappings behind an anonymous file allows (ab)use of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. To limit fragmentation of the direct map to splitting only PUD-size pages, I've added an amortizing cache of PMD-size pages to each file descriptor that is used as an allocation pool for the secret memory areas. As the memory allocated by secretmem becomes unmovable, we use CMA to back large page caches so that page allocator won't be surprised by failing attempt to migrate these pages. v13: * Added Reviewed-by, thanks Catalin and David * s/mod_node_page_state/mod_lruvec_page_state/ as Shakeel suggested v12: https://lore.kernel.org/lkml/20201125092208.12544-1-r...@kernel.org * Add detection of whether set_direct_map has actual effect on arm64 and bail out of CMA allocation for secretmem and the memfd_secret() syscall if pages would not be removed from the direct map v11: https://lore.kernel.org/lkml/20201124092556.12009-1-r...@kernel.org * Drop support for uncached mappings v10: https://lore.kernel.org/lkml/20201123095432.5860-1-r...@kernel.org * Drop changes to arm64 compatibility layer * Add Roman's Ack for memcg accounting v9: https://lore.kernel.org/lkml/20201117162932.13649-1-r...@kernel.org * Fix build with and without CONFIG_MEMCG * Update memcg accounting to avoid copying memcg_data, per Roman comments * Fix issues in secretmem_fault(), thanks Matthew * Do not wire up syscall in arm64 compatibility layer Older history: v8: https://lore.kernel.org/lkml/20201110151444.20662-1-r...@kernel.org v7: https://lore.kernel.org/lkml/20201026083752.13267-1-r...@kernel.org v6: https://lore.kernel.org/lkml/20200924132904.1391-1-r...@kernel.org v5: https://lore.kernel.org/lkml/20200916073539.3552-1-r...@kernel.org v4: https://lore.kernel.org/lkml/20200818141554.13945-1-r...@kernel.org v3: https://lore.kernel.org/lkml/20200804095035.18778-1-r...@kernel.org v2: https://lore.kernel.org/lkml/20200727162935.31714-1-r...@kernel.org v1: https://lore.kernel.org/lkml/20200720092435.17469-1-r...@kernel.org Mike Rapoport (10): mm: add definition of PMD_PAGE_ORDER mmap: make mlock_future_check() global set_memory: allow set_direct_map_*_noflush() for multiple pages set_memory: allow querying whether set_direct_map_*() is actually enabled mm: introduce memfd_secret system call to create "secret" memory areas secretmem: use PMD-size pages to amortize direct map fragmentation secretmem: add memcg accounting PM: hibernate: disable when there are active secretmem users arch, mm: wire up memfd_secret system call were relevant secretmem: test: add basic selftest for memfd_secret(2) arch/arm64/include/asm/Kbuild | 1 - arch/arm64/include/asm/cacheflush.h | 6 - arch/arm64/include/asm/set_memory.h | 17 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/arm64/kernel/machine_kexec.c | 1 + arch/arm64/mm/mmu.c | 6 +- arch/arm64/mm/pageattr.c |
[PATCH v13 01/10] mm: add definition of PMD_PAGE_ORDER
From: Mike Rapoport
The definition of PMD_PAGE_ORDER denoting the number of base pages in the
second-level leaf page is already used by DAX and maybe handy in other
cases as well.
Several architectures already have definition of PMD_ORDER as the size of
second level page table, so to avoid conflict with these definitions use
PMD_PAGE_ORDER name and update DAX respectively.
Signed-off-by: Mike Rapoport
Reviewed-by: David Hildenbrand
---
fs/dax.c| 11 ---
include/linux/pgtable.h | 3 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 26d5dcd2d69e..0f109eb16196 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -49,9 +49,6 @@ static inline unsigned int pe_order(enum page_entry_size
pe_size)
#define PG_PMD_COLOUR ((PMD_SIZE >> PAGE_SHIFT) - 1)
#define PG_PMD_NR (PMD_SIZE >> PAGE_SHIFT)
-/* The order of a PMD entry */
-#define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
-
static wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
static int __init init_dax_wait_table(void)
@@ -98,7 +95,7 @@ static bool dax_is_locked(void *entry)
static unsigned int dax_entry_order(void *entry)
{
if (xa_to_value(entry) & DAX_PMD)
- return PMD_ORDER;
+ return PMD_PAGE_ORDER;
return 0;
}
@@ -1470,7 +1467,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault
*vmf, pfn_t *pfnp,
{
struct vm_area_struct *vma = vmf->vma;
struct address_space *mapping = vma->vm_file->f_mapping;
- XA_STATE_ORDER(xas, >i_pages, vmf->pgoff, PMD_ORDER);
+ XA_STATE_ORDER(xas, >i_pages, vmf->pgoff, PMD_PAGE_ORDER);
unsigned long pmd_addr = vmf->address & PMD_MASK;
bool write = vmf->flags & FAULT_FLAG_WRITE;
bool sync;
@@ -1529,7 +1526,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault
*vmf, pfn_t *pfnp,
* entry is already in the array, for instance), it will return
* VM_FAULT_FALLBACK.
*/
- entry = grab_mapping_entry(, mapping, PMD_ORDER);
+ entry = grab_mapping_entry(, mapping, PMD_PAGE_ORDER);
if (xa_is_internal(entry)) {
result = xa_to_internal(entry);
goto fallback;
@@ -1695,7 +1692,7 @@ dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn,
unsigned int order)
if (order == 0)
ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
#ifdef CONFIG_FS_DAX_PMD
- else if (order == PMD_ORDER)
+ else if (order == PMD_PAGE_ORDER)
ret = vmf_insert_pfn_pmd(vmf, pfn, FAULT_FLAG_WRITE);
#endif
else
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 71125a4676c4..7f718b8dc789 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -28,6 +28,9 @@
#define USER_PGTABLES_CEILING 0UL
#endif
+/* Number of base pages in a second level leaf page */
+#define PMD_PAGE_ORDER (PMD_SHIFT - PAGE_SHIFT)
+
/*
* A page table page can be thought of an array like this: pXd_t[PTRS_PER_PxD]
*
--
2.28.0
Re: [PATCH] INPUT: xpad: support Ardwiino Controllers
Hi Sanjay,
On Tue, Dec 01, 2020 at 08:19:23PM +1300, sanjay.govi...@gmail.com wrote:
> From: Sanjay Govind
>
> This commit adds support for Ardwiino Controllers
>
> Signed-off-by: Sanjay Govind
> ---
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index c77cdb3b62b5..91a5c7e7bdd2 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -245,6 +245,7 @@ static const struct xpad_device {
> { 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
> { 0x12ab, 0x0303, "Mortal Kombat Klassic FightStick",
> MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
> { 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX
> },
> + { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
I moved this line above the entries for 12ab vendor and applied, thank
you.
> { 0x1430, 0x4748, "RedOctane Guitar Hero X-plorer", 0, XTYPE_XBOX360 },
> { 0x1430, 0x, "TX6500+ Dance Pad (first generation)",
> MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
> { 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
> @@ -418,6 +419,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOXONE_VENDOR(0x0f0d),/* Hori Controllers */
> XPAD_XBOX360_VENDOR(0x1038),/* SteelSeries Controllers */
> XPAD_XBOX360_VENDOR(0x11c9),/* Nacon GC100XF */
> + XPAD_XBOX360_VENDOR(0x1209),/* Ardwiino Controllers */
> XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
> XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360
> controllers */
> XPAD_XBOX360_VENDOR(0x146b),/* BigBen Interactive
> Controllers */
> --
> 2.29.2
>
--
Dmitry
general protection fault in workingset_age_nonresident
Hello, syzbot found the following issue on: HEAD commit:c6b11acc Add linux-next specific files for 20201130 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1074103d50 kernel config: https://syzkaller.appspot.com/x/.config?x=b5e03844e9b34d37 dashboard link: https://syzkaller.appspot.com/bug?extid=8f327e215a9398a664b7 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8f327e215a9398a66...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc017c027e8b: [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x000be013f458-0x000be013f45f] CPU: 0 PID: 13851 Comm: syz-executor.5 Not tainted 5.10.0-rc5-next-20201130-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:629 [inline] RIP: 0010:parent_lruvec include/linux/memcontrol.h:1560 [inline] RIP: 0010:workingset_age_nonresident+0x13a/0x1c0 mm/workingset.c:242 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 88 00 00 00 49 8b 9c dc 58 0d 00 00 e8 a4 67 cf ff 48 8d bb c0 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 75 56 4c 3b ab c0 00 00 00 75 2b e8 82 67 cf ff 48 85 RSP: 0018:c9000c0074c0 EFLAGS: 00010006 RAX: 00017c027e8b RBX: 000be013f39a RCX: c90013eb6000 RDX: 0004 RSI: 81a159ac RDI: 000be013f45a RBP: dc00 R08: 0001 R09: 88813dbf R10: ed1027b7 R11: R12: 8e790e30 R13: 88813fffb000 R14: 0001 R15: 8e790d10 FS: 7fba638dc700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fba638dbdb8 CR3: 29181000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: workingset_eviction+0x452/0x9b0 mm/workingset.c:266 __remove_mapping+0x867/0xd20 mm/vmscan.c:927 shrink_page_list+0x246a/0x5e80 mm/vmscan.c:1431 reclaim_pages+0x3e2/0xcd0 mm/vmscan.c:2148 madvise_cold_or_pageout_pte_range+0x1615/0x2880 mm/madvise.c:473 walk_pmd_range mm/pagewalk.c:89 [inline] walk_pud_range mm/pagewalk.c:160 [inline] walk_p4d_range mm/pagewalk.c:193 [inline] walk_pgd_range mm/pagewalk.c:229 [inline] __walk_page_range+0xda4/0x1e20 mm/pagewalk.c:331 walk_page_range+0x1be/0x450 mm/pagewalk.c:427 madvise_pageout_page_range mm/madvise.c:526 [inline] madvise_pageout+0x21b/0x390 mm/madvise.c:562 madvise_vma mm/madvise.c:943 [inline] do_madvise.part.0+0x9f2/0x1ed0 mm/madvise.c:1142 do_madvise mm/madvise.c:1168 [inline] __do_sys_madvise mm/madvise.c:1168 [inline] __se_sys_madvise mm/madvise.c:1166 [inline] __x64_sys_madvise+0x113/0x150 mm/madvise.c:1166 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fba638dbc78 EFLAGS: 0246 ORIG_RAX: 001c RAX: ffda RBX: 00020ec0 RCX: 0045deb9 RDX: 0015 RSI: 0063 RDI: 2000 RBP: 0118c0b0 R08: R09: R10: R11: 0246 R12: 0118c07c R13: 7ffe3594576f R14: 7fba638dc9c0 R15: 0118c07c Modules linked in: ---[ end trace 55e42525eeb89bbe ]--- RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:629 [inline] RIP: 0010:parent_lruvec include/linux/memcontrol.h:1560 [inline] RIP: 0010:workingset_age_nonresident+0x13a/0x1c0 mm/workingset.c:242 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 88 00 00 00 49 8b 9c dc 58 0d 00 00 e8 a4 67 cf ff 48 8d bb c0 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 75 56 4c 3b ab c0 00 00 00 75 2b e8 82 67 cf ff 48 85 RSP: 0018:c9000c0074c0 EFLAGS: 00010006 RAX: 00017c027e8b RBX: 000be013f39a RCX: c90013eb6000 RDX: 0004 RSI: 81a159ac RDI: 000be013f45a RBP: dc00 R08: 0001 R09: 88813dbf R10: ed1027b7 R11: R12: 8e790e30 R13: 88813fffb000 R14: 0001 R15: 8e790d10 FS: 7fba638dc700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fba638dbdb8 CR3: 29181000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more
Re: [PATCH] staging:media:zoran: Fixed grammar issue
On Mon, Nov 30, 2020 at 05:06:59PM -0600, Travis Carter wrote: > Removed repeated word 'in' > > Signed-off-by: Travis Carter > --- > drivers/staging/media/zoran/zoran_card.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/zoran/zoran_card.c > b/drivers/staging/media/zoran/zoran_card.c > index dfc60e2e9dd7..c77aa458b6d2 100644 > --- a/drivers/staging/media/zoran/zoran_card.c > +++ b/drivers/staging/media/zoran/zoran_card.c > @@ -39,7 +39,7 @@ MODULE_PARM_DESC(card, "Card type"); > /* > * The video mem address of the video card. The driver has a little database > for some videocards > * to determine it from there. If your video card is not in there you have > either to give it to > - * the driver as a parameter or set in in a VIDIOCSFBUF ioctl > + * the driver as a parameter or set in a VIDIOCSFBUF ioctl > */ > > static unsigned long vidmem; /* default = 0 - Video memory base address */ > -- > 2.17.1 > Hello Acked-by: Corentin Labbe Thanks
回复: INFO: task hung in ath6kl_usb_destroy (3)
发件人: syzbot
发送时间: 2020年11月30日 23:31
收件人: andreyk...@google.com; da...@davemloft.net; k...@kernel.org;
kv...@codeaurora.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
linux-wirel...@vger.kernel.org; net...@vger.kernel.org;
syzkaller-b...@googlegroups.com
主题: INFO: task hung in ath6kl_usb_destroy (3)
[Please note this e-mail is from an EXTERNAL e-mail address]
Hello,
syzbot found the following issue on:
HEAD commit:ebad4326 Merge 5.10-rc6 into usb-next
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1566291d50
kernel config: https://syzkaller.appspot.com/x/.config?x=fe8988e4dc252d01
dashboard link: https://syzkaller.appspot.com/bug?extid=bccb3d118a39c43b6c9d
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bccb3d118a39c43b6...@syzkaller.appspotmail.com
INFO: task kworker/1:4:7246 blocked for more than 143 seconds.
Not tainted 5.10.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:4 state:D stack:22864 pid: 7246 ppid: 2 flags:0x4000
Workqueue: usb_hub_wq hub_event
Call Trace:
context_switch kernel/sched/core.c:3779 [inline]
__schedule+0x8a2/0x1f30 kernel/sched/core.c:4528
schedule+0xcb/0x270 kernel/sched/core.c:4606
schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1847
do_wait_for_common kernel/sched/completion.c:85 [inline]
__wait_for_common kernel/sched/completion.c:106 [inline]
wait_for_common kernel/sched/completion.c:117 [inline]
wait_for_completion+0x168/0x270 kernel/sched/completion.c:138
flush_workqueue+0x3ff/0x13e0 kernel/workqueue.c:2835
flush_scheduled_work include/linux/workqueue.h:597 [inline]
ath6kl_usb_flush_all drivers/net/wireless/ath/ath6kl/usb.c:476 [inline]
void ath6kl_usb_flush_all
flush_scheduled_work
call "flush_scheduled_work" function to flush all work in system_wq?
should "flush_work" need to be called?
ath6kl_usb_destroy+0xc6/0x290 drivers/net/wireless/ath/ath6kl/usb.c:609
ath6kl_usb_probe+0xc7b/0x11f0 drivers/net/wireless/ath/ath6kl/usb.c:1166
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
really_probe+0x291/0xde0 drivers/base/dd.c:554
driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738
__device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4a0 drivers/base/dd.c:912
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbb2/0x1ce0 drivers/base/core.c:2936
usb_set_configuration+0x113c/0x1910 drivers/usb/core/message.c:2168
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
really_probe+0x291/0xde0 drivers/base/dd.c:554
driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738
__device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x228/0x4a0 drivers/base/dd.c:912
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xbb2/0x1ce0 drivers/base/core.c:2936
usb_new_device.cold+0x71d/0xfe9 drivers/usb/core/hub.c:2555
hub_port_connect drivers/usb/core/hub.c:5223 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
port_event drivers/usb/core/hub.c:5509 [inline]
hub_event+0x2348/0x42d0 drivers/usb/core/hub.c:5591
process_one_work+0x933/0x1520 kernel/workqueue.c:2272
process_scheduled_works kernel/workqueue.c:2334 [inline]
worker_thread+0x82b/0x1120 kernel/workqueue.c:2420
kthread+0x38c/0x460 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Showing all locks held in the system:
5 locks held by kworker/0:0/5:
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:856 [inline]
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at:
atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at:
set_work_data kernel/workqueue.c:616 [inline]
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
#0: 888103c7ed38 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at:
process_one_work+0x821/0x1520 kernel/workqueue.c:2243
#1: c905fda8 ((work_completion)(>events)){+.+.}-{0:0}, at:
process_one_work+0x854/0x1520 kernel/workqueue.c:2247
#2: 888108dd6218 (>mutex){}-{3:3}, at: device_lock
include/linux/device.h:731 [inline]
#2: 888108dd6218 (>mutex){}-{3:3}, at:
[PATCH v2 1/2] dt-bindings: arm: fsl: add Protonic MVT board
Add Protonic MVT imx6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 8abe71b8646d..ad95b29268d3 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -371,6 +371,7 @@ properties: - ply,plybas# Plymovent BAS board - ply,plym2m# Plymovent M2M board - poslab,imx6dl-savageboard # Poslab SavageBoard Dual + - prt,prtmvt# Protonic MVT board - prt,prtrvt# Protonic RVT board - prt,prtvt7# Protonic VT7 board - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board -- 2.29.2
[PATCH v2 0/2] mainline Protonic MVT board
changes v2: - fix active level of SPI CS GPIOs Oleksij Rempel (2): dt-bindings: arm: fsl: add Protonic MVT board ARM: dts: add Protonic MVT board .../devicetree/bindings/arm/fsl.yaml | 1 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6dl-prtmvt.dts | 851 ++ 3 files changed, 853 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-prtmvt.dts -- 2.29.2
[PATCH v2 2/2] ARM: dts: add Protonic MVT board
PRTMVT is the reference platform for Protonic industrial touchscreen terminals.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtmvt.dts | 851
2 files changed, 852 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtmvt.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b309420975a9..d15442a464a3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -463,6 +463,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-pi.dtb \
imx6dl-plybas.dtb \
imx6dl-plym2m.dtb \
+ imx6dl-prtmvt.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtmvt.dts
b/arch/arm/boot/dts/imx6dl-prtmvt.dts
new file mode 100644
index ..f6a5e98a6fa7
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtmvt.dts
@@ -0,0 +1,851 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Protonic MVT board";
+ compatible = "prt,prtmvt", "fsl,imx6dl";
+
+ chosen {
+ stdout-path =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ pwms = < 0 500 0>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <1>;
+ power-supply = <_3v3>;
+ enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ connector {
+ compatible = "composite-video-connector";
+ label = "Composite0";
+ sdtv-standards = ;
+
+ port {
+ comp0_out: endpoint {
+ remote-endpoint = <_comp0_in>;
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpiokeys>;
+ autorepeat;
+
+ power {
+ label = "Power Button";
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ linux,code = <116>; /* KEY_POWER */
+ wakeup-source;
+ };
+
+ f1 {
+ label = "GPIO Key F1";
+ linux,code = <59>;
+ gpios = <_pca 0 GPIO_ACTIVE_LOW>;
+ };
+
+ f2 {
+ label = "GPIO Key F2";
+ linux,code = <60>;
+ gpios = <_pca 1 GPIO_ACTIVE_LOW>;
+ };
+
+ f3 {
+ label = "GPIO Key F3";
+ linux,code = <61>;
+ gpios = <_pca 2 GPIO_ACTIVE_LOW>;
+ };
+
+ f4 {
+ label = "GPIO Key F4";
+ linux,code = <62>;
+ gpios = <_pca 3 GPIO_ACTIVE_LOW>;
+ };
+
+ f5 {
+ label = "GPIO Key F5";
+ linux,code = <63>;
+ gpios = <_pca 4 GPIO_ACTIVE_LOW>;
+ };
+
+ cycle {
+ label = "GPIO Key CYCLE";
+ linux,code = <154>;
+ gpios = <_pca 5 GPIO_ACTIVE_LOW>;
+ };
+
+ esc {
+ label = "GPIO Key ESC";
+ linux,code = <1>;
+ gpios = <_pca 6 GPIO_ACTIVE_LOW>;
+ };
+
+ up {
+ label = "GPIO Key UP";
+ linux,code = <103>;
+ gpios = <_pca 7 GPIO_ACTIVE_LOW>;
+ };
+
+ down {
+ label = "GPIO Key DOWN";
+ linux,code = <108>;
+ gpios = <_pca 8 GPIO_ACTIVE_LOW>;
+ };
+
+ ok {
+ label = "GPIO Key OK";
+ linux,code = <0x160>;
+ gpios = <_pca 9 GPIO_ACTIVE_LOW>;
+ };
+
+ f6 {
+ label = "GPIO Key F6";
+ linux,code = <64>;
+ gpios = <_pca 10 GPIO_ACTIVE_LOW>;
+ };
+
+ f7 {
+ label = "GPIO Key F7";
+ linux,code = <65>;
+ gpios = <_pca 11 GPIO_ACTIVE_LOW>;
+ };
+
+ f8 {
+ label = "GPIO Key F8";
+ linux,code =
Re: [PATCH v3] RISC-V: Use SBI SRST extension when available
On Tue, Nov 24, 2020 at 9:18 PM Anup Patel wrote:
>
> The SBI SRST extension provides a standard way to poweroff and
> reboot the system irrespective to whether Linux RISC-V S-mode
> is running natively (HS-mode) or inside Guest/VM (VS-mode).
>
> The SBI SRST extension is available in latest SBI v0.3-draft
> specification at: https://github.com/riscv/riscv-sbi-doc.
>
> This patch extends Linux RISC-V SBI implementation to detect
> and use SBI SRST extension.
>
> Signed-off-by: Anup Patel
> ---
> Changes since v2:
> - Rebased on Linux-5.10-rc5
> - Updated patch as-per SBI SRST extension available in the latest
>SBI v0.3-draft specification
> Changes since v1:
> - Updated patch as-per latest SBI SRST extension draft spec where
>we have only one SBI call with "reset_type" parameter
> ---
> arch/riscv/include/asm/sbi.h | 16
> arch/riscv/kernel/sbi.c | 34 ++
> 2 files changed, 50 insertions(+)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 653edb25d495..5b2d6d614c20 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -27,6 +27,7 @@ enum sbi_ext_id {
> SBI_EXT_IPI = 0x735049,
> SBI_EXT_RFENCE = 0x52464E43,
> SBI_EXT_HSM = 0x48534D,
> + SBI_EXT_SRST = 0x53525354,
> };
>
> enum sbi_ext_base_fid {
> @@ -70,6 +71,21 @@ enum sbi_hsm_hart_status {
> SBI_HSM_HART_STATUS_STOP_PENDING,
> };
>
> +enum sbi_ext_srst_fid {
> + SBI_EXT_SRST_RESET = 0,
> +};
> +
> +enum sbi_srst_reset_type {
> + SBI_SRST_RESET_TYPE_SHUTDOWN = 0,
> + SBI_SRST_RESET_TYPE_COLD_REBOOT,
> + SBI_SRST_RESET_TYPE_WARM_REBOOT,
> +};
> +
> +enum sbi_srst_reset_reason {
> + SBI_SRST_RESET_REASON_NONE = 0,
> + SBI_SRST_RESET_REASON_SYS_FAILURE,
> +};
> +
> #define SBI_SPEC_VERSION_DEFAULT 0x1
> #define SBI_SPEC_VERSION_MAJOR_SHIFT 24
> #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index 226ccce0f9e0..33b834ecd195 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -501,6 +502,32 @@ int sbi_remote_hfence_vvma_asid(const unsigned long
> *hart_mask,
> }
> EXPORT_SYMBOL(sbi_remote_hfence_vvma_asid);
>
> +static void sbi_srst_reset(unsigned long type, unsigned long reason)
> +{
> + sbi_ecall(SBI_EXT_SRST, SBI_EXT_SRST_RESET, type, reason,
> + 0, 0, 0, 0);
> + pr_warn("%s: type=0x%lx reason=0x%lx failed\n",
> + __func__, type, reason);
sbi_system_reset may return the failure reason as well. I think we can
print that in the warning message if present.
> +}
> +
> +static int sbi_srst_reboot(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + sbi_srst_reset((mode == REBOOT_WARM || mode == REBOOT_SOFT) ?
> + SBI_SRST_RESET_TYPE_WARM_REBOOT :
> + SBI_SRST_RESET_TYPE_COLD_REBOOT,
> + SBI_SRST_RESET_REASON_NONE);
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block sbi_srst_reboot_nb;
> +
> +static void sbi_srst_power_off(void)
> +{
> + sbi_srst_reset(SBI_SRST_RESET_TYPE_SHUTDOWN,
> + SBI_SRST_RESET_REASON_NONE);
> +}
> +
> /**
> * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
> * @extid: The extension ID to be probed.
> @@ -593,6 +620,13 @@ int __init sbi_init(void)
> } else {
> __sbi_rfence= __sbi_rfence_v01;
> }
> + if (sbi_probe_extension(SBI_EXT_SRST) > 0) {
> + pr_info("SBI v0.2 SRST extension detected\n");
> + pm_power_off = sbi_srst_power_off;
> + sbi_srst_reboot_nb.notifier_call = sbi_srst_reboot;
> + sbi_srst_reboot_nb.priority = 192;
> + register_restart_handler(_srst_reboot_nb);
> + }
> } else {
> __sbi_set_timer = __sbi_set_timer_v01;
> __sbi_send_ipi = __sbi_send_ipi_v01;
> --
> 2.25.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Apart from that, it looks good to me.
Reviewed-by: Atish Patra
--
Regards,
Atish
Re: [PATCH] scsi: ufs: clear uac for RPMB after ufshcd resets
Hi Jaegeuk,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on scsi/for-next]
[also build test WARNING on mkp-scsi/for-next linux/master linus/master
v5.10-rc6 next-20201130]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jaegeuk-Kim/scsi-ufs-clear-uac-for-RPMB-after-ufshcd-resets/20201201-121956
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-randconfig-a006-20201201 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ac40a2d8f16b8a8c68fc811d67f647740e965cb8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/0636adf2e8880085b18818ce6e7ee878189b52ca
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jaegeuk-Kim/scsi-ufs-clear-uac-for-RPMB-after-ufshcd-resets/20201201-121956
git checkout 0636adf2e8880085b18818ce6e7ee878189b52ca
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/scsi/ufs/ufshcd.c:8398:1: warning: unused label 'out'
>> [-Wunused-label]
out:
^~~~
1 warning generated.
vim +/out +8398 drivers/scsi/ufs/ufshcd.c
57d104c153d3d6d Subhash Jadavani 2014-09-25 8335
57d104c153d3d6d Subhash Jadavani 2014-09-25 8336 /**
57d104c153d3d6d Subhash Jadavani 2014-09-25 8337 * ufshcd_set_dev_pwr_mode
- sends START STOP UNIT command to set device
57d104c153d3d6d Subhash Jadavani 2014-09-25 8338 *
power mode
57d104c153d3d6d Subhash Jadavani 2014-09-25 8339 * @hba: per adapter
instance
57d104c153d3d6d Subhash Jadavani 2014-09-25 8340 * @pwr_mode: device power
mode to set
57d104c153d3d6d Subhash Jadavani 2014-09-25 8341 *
57d104c153d3d6d Subhash Jadavani 2014-09-25 8342 * Returns 0 if requested
power mode is set successfully
57d104c153d3d6d Subhash Jadavani 2014-09-25 8343 * Returns non-zero if
failed to set the requested power mode
57d104c153d3d6d Subhash Jadavani 2014-09-25 8344 */
57d104c153d3d6d Subhash Jadavani 2014-09-25 8345 static int
ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
57d104c153d3d6d Subhash Jadavani 2014-09-25 8346
enum ufs_dev_pwr_mode pwr_mode)
57d104c153d3d6d Subhash Jadavani 2014-09-25 8347 {
57d104c153d3d6d Subhash Jadavani 2014-09-25 8348 unsigned char cmd[6] =
{ START_STOP };
57d104c153d3d6d Subhash Jadavani 2014-09-25 8349 struct scsi_sense_hdr
sshdr;
7c48bfd038e570c Akinobu Mita 2014-10-23 8350 struct scsi_device *sdp;
7c48bfd038e570c Akinobu Mita 2014-10-23 8351 unsigned long flags;
57d104c153d3d6d Subhash Jadavani 2014-09-25 8352 int ret;
57d104c153d3d6d Subhash Jadavani 2014-09-25 8353
7c48bfd038e570c Akinobu Mita 2014-10-23 8354
spin_lock_irqsave(hba->host->host_lock, flags);
7c48bfd038e570c Akinobu Mita 2014-10-23 8355 sdp =
hba->sdev_ufs_device;
7c48bfd038e570c Akinobu Mita 2014-10-23 8356 if (sdp) {
7c48bfd038e570c Akinobu Mita 2014-10-23 8357 ret =
scsi_device_get(sdp);
7c48bfd038e570c Akinobu Mita 2014-10-23 8358 if (!ret &&
!scsi_device_online(sdp)) {
7c48bfd038e570c Akinobu Mita 2014-10-23 8359 ret =
-ENODEV;
7c48bfd038e570c Akinobu Mita 2014-10-23 8360
scsi_device_put(sdp);
7c48bfd038e570c Akinobu Mita 2014-10-23 8361 }
7c48bfd038e570c Akinobu Mita 2014-10-23 8362 } else {
7c48bfd038e570c Akinobu Mita 2014-10-23 8363 ret = -ENODEV;
7c48bfd038e570c Akinobu Mita 2014-10-23 8364 }
7c48bfd038e570c Akinobu Mita 2014-10-23 8365
spin_unlock_irqrestore(hba->host->host_lock, flags);
7c48bfd038e570c Akinobu Mita 2014-10-23 8366
7c48bfd038e570c Akinobu Mita 2014-10-23 8367 if (ret)
7c48bfd038e570c Akinobu Mita 2014-10-23 8368 return ret;
57d104c153d3d6d Subhash Jadavani 2014-09-25 8369
57d104c153d3d6d Subhash Jadavani 2014-09-25 8370 /*
57d104c153d3d6d Subhash Jadavani 2014-09-25 8371 * If scsi commands
fail, the scsi mid-layer schedules scsi error-
57d104c153d3d6d Subhash Jadavani 2014-09-25 8372 * handling,
BUG: unable to handle kernel paging request in workingset_age_nonresident
Hello,
syzbot found the following issue on:
HEAD commit:c6b11acc Add linux-next specific files for 20201130
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=114b94e950
kernel config: https://syzkaller.appspot.com/x/.config?x=b5e03844e9b34d37
dashboard link: https://syzkaller.appspot.com/bug?extid=a59e7ceb87a83c5233df
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=150fed8b50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1726291d50
The issue was bisected to:
commit 76761ffa9ea1ddca78e817bf7eec5fcb0378a00c
Author: Alex Shi
Date: Sun Nov 29 23:58:06 2020 +
mm/memcg: bail out early when !memcg in mem_cgroup_lruvec
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=122ff44550
final oops: https://syzkaller.appspot.com/x/report.txt?x=112ff44550
console output: https://syzkaller.appspot.com/x/log.txt?x=162ff44550
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a59e7ceb87a83c523...@syzkaller.appspotmail.com
Fixes: 76761ffa9ea1 ("mm/memcg: bail out early when !memcg in
mem_cgroup_lruvec")
BUG: unable to handle page fault for address: 81417c79
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD b08f067 P4D b08f067 PUD b090063 PMD 14001e1
Oops: 0003 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8503 Comm: syz-executor118 Not tainted
5.10.0-rc5-next-20201130-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:630 [inline]
RIP: 0010:parent_lruvec include/linux/memcontrol.h:1560 [inline]
RIP: 0010:workingset_age_nonresident+0x179/0x1c0 mm/workingset.c:242
Code: 85 db 0f 85 c8 fe ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f e9 6a 67 cf ff e8
65 67 cf ff 49 8d 9d 18 4d 00 00 eb b3 e8 57 67 cf ff <4c> 89 ab c0 00 00 00 eb
c7 e8 69 35 12 00 e9 d3 fe ff ff e8 5f 35
RSP: 0018:c9000112f4c0 EFLAGS: 00010093
RAX: RBX: 81417bb9 RCX:
RDX: 88801eee5040 RSI: 81a159f9 RDI: 81417c79
RBP: dc00 R08: 0001 R09: 88813dbf
R10: ed1027b7 R11: R12: 8e7911d0
R13: 88813fffb000 R14: 0001 R15: 8e7910b0
FS: 02581880() GS:8880b9f0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 81417c79 CR3: 13a2f000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
workingset_eviction+0x452/0x9b0 mm/workingset.c:266
__remove_mapping+0x867/0xd20 mm/vmscan.c:927
shrink_page_list+0x246a/0x5e80 mm/vmscan.c:1431
reclaim_pages+0x3e2/0xcd0 mm/vmscan.c:2148
madvise_cold_or_pageout_pte_range+0x1615/0x2880 mm/madvise.c:473
walk_pmd_range mm/pagewalk.c:89 [inline]
walk_pud_range mm/pagewalk.c:160 [inline]
walk_p4d_range mm/pagewalk.c:193 [inline]
walk_pgd_range mm/pagewalk.c:229 [inline]
__walk_page_range+0xda4/0x1e20 mm/pagewalk.c:331
walk_page_range+0x1be/0x450 mm/pagewalk.c:427
madvise_pageout_page_range mm/madvise.c:526 [inline]
madvise_pageout+0x21b/0x390 mm/madvise.c:562
madvise_vma mm/madvise.c:943 [inline]
do_madvise.part.0+0x9f2/0x1ed0 mm/madvise.c:1142
do_madvise mm/madvise.c:1168 [inline]
__do_sys_madvise mm/madvise.c:1168 [inline]
__se_sys_madvise mm/madvise.c:1166 [inline]
__x64_sys_madvise+0x113/0x150 mm/madvise.c:1166
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440279
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffe7c1ab298 EFLAGS: 0246 ORIG_RAX: 001c
RAX: ffda RBX: 004002c8 RCX: 00440279
RDX: 0015 RSI: 0063 RDI: 2000
RBP: 006ca018 R08: R09:
R10: 0004 R11: 0246 R12: 00401a80
R13: 00401b10 R14: R15:
Modules linked in:
CR2: 81417c79
---[ end trace 89bcebda47215cf6 ]---
RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:630 [inline]
RIP: 0010:parent_lruvec include/linux/memcontrol.h:1560 [inline]
RIP: 0010:workingset_age_nonresident+0x179/0x1c0 mm/workingset.c:242
Code: 85 db 0f 85 c8 fe ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f e9 6a 67 cf ff e8
65 67 cf ff 49 8d 9d 18 4d 00 00 eb b3 e8 57 67 cf ff <4c> 89 ab c0 00 00 00 eb
c7 e8 69 35 12 00 e9 d3 fe ff ff e8 5f 35
RSP: 0018:c9000112f4c0 EFLAGS: 00010093
RAX: RBX: 81417bb9 RCX:
RDX: 88801eee50
Re: [GIT pull] locking/urgent for v5.10-rc6
On Mon, Nov 30, 2020 at 09:55:44AM -0800, Linus Torvalds wrote: > Yes, yes, I can very well imagine some hardware doing a "idle until > you sense an interrupt, but don't actually take it". It's not > _impossible_. But it's certainly not normal. A lot of hardware actually does that, including modern x86. But yes, not nearly everything.
[RFC v2 2/2] perf-stat: enable counting events for BPF programs
Introduce perf-stat -b option, which counts events for BPF programs, like:
[root@localhost ~]# ~/perf stat -e ref-cycles,cycles -b 254 -I 1000
1.487903822115,200 ref-cycles
1.487903822 86,012 cycles
2.489147029 80,560 ref-cycles
2.489147029 73,784 cycles
3.490341825 60,720 ref-cycles
3.490341825 37,797 cycles
4.491540887 37,120 ref-cycles
4.491540887 31,963 cycles
The example above counts cycles and ref-cycles of BPF program of id 254.
This is similar to bpftool-prog-profile command, but more flexible.
perf-stat -b creates per-cpu perf_event and loads fentry/fexit BPF
programs (monitor-progs) to the target BPF program (target-prog). The
monitor-progs read perf_event before and after the target-prog, and
aggregate the difference in a BPF map. Then the user space reads data
from these maps.
A new struct bpf_counter is introduced to provide common interface that
uses BPF programs/maps to count perf events.
Signed-off-by: Song Liu
---
tools/perf/Makefile.perf | 2 +-
tools/perf/builtin-stat.c | 59 -
tools/perf/util/Build | 1 +
tools/perf/util/bpf_counter.c | 215 ++
tools/perf/util/bpf_counter.h | 71 ++
.../util/bpf_skel/bpf_prog_profiler.bpf.c | 96
tools/perf/util/evsel.c | 10 +
tools/perf/util/evsel.h | 5 +
tools/perf/util/target.h | 6 +
9 files changed, 456 insertions(+), 9 deletions(-)
create mode 100644 tools/perf/util/bpf_counter.c
create mode 100644 tools/perf/util/bpf_counter.h
create mode 100644 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 37b7ffe1db27c..d926f0c35ed46 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1013,7 +1013,7 @@ python-clean:
SKEL_OUT := $(abspath util/bpf_skel)
SKEL_TMP_OUT := $(abspath util/bpf_skel/.tmp)
-SKELETONS := $(SKEL_OUT)/dummy.skel.h
+SKELETONS := $(SKEL_OUT)/dummy.skel.h $(SKEL_OUT)/bpf_prog_profiler.skel.h
ifdef BUILD_BPF_SKEL
CLANG ?= clang
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f15b2f8aa14d8..d6df04cc24073 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -67,6 +67,7 @@
#include "util/top.h"
#include "util/affinity.h"
#include "util/pfm.h"
+#include "util/bpf_counter.h"
#include "asm/bug.h"
#include
@@ -409,12 +410,31 @@ static int read_affinity_counters(struct timespec *rs)
return 0;
}
+static int read_bpf_map_counters(void)
+{
+ struct evsel *counter;
+ int err;
+
+ evlist__for_each_entry(evsel_list, counter) {
+ err = bpf_counter__read(counter);
+ if (err)
+ return err;
+ }
+ return 0;
+}
+
static void read_counters(struct timespec *rs)
{
struct evsel *counter;
+ int err;
- if (!stat_config.stop_read_counter && (read_affinity_counters(rs) < 0))
- return;
+ if (!stat_config.stop_read_counter) {
+ err = read_bpf_map_counters();
+ if (err == -EAGAIN)
+ err = read_affinity_counters(rs);
+ if (err < 0)
+ return;
+ }
evlist__for_each_entry(evsel_list, counter) {
if (counter->err)
@@ -496,11 +516,20 @@ static bool handle_interval(unsigned int interval, int
*times)
return false;
}
-static void enable_counters(void)
+static int enable_counters(void)
{
+ struct evsel *evsel;
+ int err;
+
+ evlist__for_each_entry(evsel_list, evsel) {
+ err = bpf_counter__enable(evsel);
+ if (err)
+ return err;
+ }
+
if (stat_config.initial_delay < 0) {
pr_info(EVLIST_DISABLED_MSG);
- return;
+ return 0;
}
if (stat_config.initial_delay > 0) {
@@ -518,6 +547,7 @@ static void enable_counters(void)
if (stat_config.initial_delay > 0)
pr_info(EVLIST_ENABLED_MSG);
}
+ return 0;
}
static void disable_counters(void)
@@ -720,7 +750,7 @@ static int __run_perf_stat(int argc, const char **argv, int
run_idx)
const bool forks = (argc > 0);
bool is_pipe = STAT_RECORD ? perf_stat.data.is_pipe : false;
struct affinity affinity;
- int i, cpu;
+ int i, cpu, err;
bool second_pass = false;
if (forks) {
@@ -738,6 +768,11 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
if (affinity__setup() < 0)
return -1;
+ evlist__for_each_entry(evsel_list, counter) {
+ if
[RFC v2 1/2] perf: support build BPF skeletons with perf
BPF programs are useful in perf to profile BPF programs. BPF skeleton is by far the easiest way to write BPF tools. Enable building BPF skeletons in util/bpf_skel. A dummy bpf skeleton is added. More bpf skeletons will be added for different use cases. Signed-off-by: Song Liu --- tools/bpf/bpftool/Makefile | 2 ++ tools/build/Makefile.feature | 3 +- tools/perf/Makefile.config | 9 + tools/perf/Makefile.perf | 52 ++-- tools/perf/util/bpf_skel/.gitignore | 3 ++ tools/perf/util/bpf_skel/dummy.bpf.c | 19 ++ tools/scripts/Makefile.include | 1 + 7 files changed, 86 insertions(+), 3 deletions(-) create mode 100644 tools/perf/util/bpf_skel/.gitignore create mode 100644 tools/perf/util/bpf_skel/dummy.bpf.c diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index f60e6ad3a1dff..a01407ec78dc5 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -120,6 +120,8 @@ endif BPFTOOL_BOOTSTRAP := $(if $(OUTPUT),$(OUTPUT)bpftool-bootstrap,./bpftool-bootstrap) +bootstrap: $(BPFTOOL_BOOTSTRAP) + BOOTSTRAP_OBJS = $(addprefix $(OUTPUT),main.o common.o json_writer.o gen.o btf.o) OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature index 97cbfb31b7625..95a58b5564218 100644 --- a/tools/build/Makefile.feature +++ b/tools/build/Makefile.feature @@ -70,7 +70,8 @@ FEATURE_TESTS_BASIC := \ libaio \ libzstd\ disassembler-four-args \ -file-handle +file-handle\ +clang-bpf-co-re # FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list # of all feature tests diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index ce8516e4de34f..cb0cf06e0bb43 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -621,6 +621,15 @@ ifndef NO_LIBBPF endif endif +ifeq ($(feature-clang-bpf-co-re), 0) + BUILD_BPF_SKEL := 0 +endif + +ifeq ($(BUILD_BPF_SKEL), 1) + $(call detected,CONFIG_PERF_BPF_SKEL) + CFLAGS += -DBUILD_BPF_SKEL +endif + dwarf-post-unwind := 1 dwarf-post-unwind-text := BUG diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 7ce3f2e8b9c74..37b7ffe1db27c 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -126,6 +126,8 @@ include ../scripts/utilities.mak # # Define NO_LIBDEBUGINFOD if you do not want support debuginfod # +# Define BUILD_BPF_SKEL to enable BPF skeletons +# # As per kernel Makefile, avoid funny character set dependencies unexport LC_ALL @@ -735,7 +737,8 @@ prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h archheaders $(drm_ioc $(x86_arch_prctl_code_array) \ $(rename_flags_array) \ $(arch_errno_name_array) \ - $(sync_file_range_arrays) + $(sync_file_range_arrays) \ + bpf-skel $(OUTPUT)%.o: %.c prepare FORCE $(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@ @@ -1008,7 +1011,52 @@ config-clean: python-clean: $(python-clean) -clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean +SKEL_OUT := $(abspath util/bpf_skel) +SKEL_TMP_OUT := $(abspath util/bpf_skel/.tmp) +SKELETONS := $(SKEL_OUT)/dummy.skel.h + +ifdef BUILD_BPF_SKEL +CLANG ?= clang +LLVM_STRIP ?= llvm-strip +BPFTOOL_CFLAGS := $(filter-out -D_GNU_SOURCE,$(CFLAGS)) +BPFTOOL := $(SKEL_TMP_OUT)/bpftool-bootstrap +LIBBPF_SRC := $(abspath ../lib/bpf) +BPFOBJ := $(SKEL_TMP_OUT)/libbpf.a +BPF_INCLUDE := $(SKEL_TMP_OUT) +submake_extras := feature_display=0 + +$(SKEL_TMP_OUT): + $(Q)$(MKDIR) -p $@ + +$(BPFTOOL): | $(SKEL_TMP_OUT) + CFLAGS= $(MAKE) $(submake_extras) -C ../bpf/bpftool \ + OUTPUT=$(SKEL_TMP_OUT)/ bootstrap + +$(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(BPFOBJ) | $(SKEL_TMP_OUT) + $(call QUIET_CLANG, $@) + $(Q)$(CLANG) -g -O2 -target bpf -c $(filter util/bpf_skel/%.bpf.c,$^) -o $@ && \ + $(LLVM_STRIP) -g $@ + +$(SKEL_OUT)/%.skel.h: $(SKEL_TMP_OUT)/%.bpf.o | $(BPFTOOL) + $(call QUIET_GENSKEL, $@) + $(Q)$(BPFTOOL) gen skeleton $< > $@ + +bpf-skel: $(SKELETONS) + +$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(SKEL_TMP_OUT) + $(Q)$(MAKE) $(submake_extras) -C $(LIBBPF_SRC) \ + OUTPUT=$(abspath $(dir $@))/ $(abspath $@) + +else # BUILD_BPF_SKEL + +bpf-skel: + +endif # BUILD_BPF_SKEL + +bpf-skel-clean: + $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS) + +clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean bpf-skel-clean $(call QUIET_CLEAN, core-objs) $(RM) $(LIBPERF_A)
[RFC v2 0/2] Introduce perf-stat -b for BPF programs
This set introduces perf-stat -b option to count events for BPF programs. This is similar to bpftool-prog-profile. But perf-stat makes it much more flexible. Sending as RFC because I haven't addressed some known limitations: 1. Only counting events for one BPF program at a time. 2. Need extra logic in target__validate(). Changes RFCv1 => RFCv2: 1. Use bootstrap version of bpftool. (Jiri) 2. Set default to not building bpf skeletons. (Jiri) 3. Remove util/bpf_skel/Makefile, keep all the logic in Makefile.perf. (Jiri) 4. Remove dependency to vmlinux.h in the two skeletons. The goal here is to enable building perf without building kernel (vmlinux) first. Note: I also removed the logic that build vmlinux.h. We can add that back when we have to use it (to access big kernel structures). Song Liu (2): perf: support build BPF skeletons with perf perf-stat: enable counting events for BPF programs tools/bpf/bpftool/Makefile| 2 + tools/build/Makefile.feature | 3 +- tools/perf/Makefile.config| 9 + tools/perf/Makefile.perf | 52 - tools/perf/builtin-stat.c | 59 - tools/perf/util/Build | 1 + tools/perf/util/bpf_counter.c | 215 ++ tools/perf/util/bpf_counter.h | 71 ++ tools/perf/util/bpf_skel/.gitignore | 3 + .../util/bpf_skel/bpf_prog_profiler.bpf.c | 96 tools/perf/util/bpf_skel/dummy.bpf.c | 19 ++ tools/perf/util/evsel.c | 10 + tools/perf/util/evsel.h | 5 + tools/perf/util/target.h | 6 + tools/scripts/Makefile.include| 1 + 15 files changed, 541 insertions(+), 11 deletions(-) create mode 100644 tools/perf/util/bpf_counter.c create mode 100644 tools/perf/util/bpf_counter.h create mode 100644 tools/perf/util/bpf_skel/.gitignore create mode 100644 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c create mode 100644 tools/perf/util/bpf_skel/dummy.bpf.c -- 2.24.1
Re: [PATCH v6 1/3] i2c: imx: Fix reset of I2SR_IAL flag
On Saturday, 10 October 2020, 13:09:20 CET, Wolfram Sang wrote:
> On Fri, Oct 09, 2020 at 01:03:18PM +0200, Christian Eggers wrote:
> > According to the "VFxxx Controller Reference Manual" (and the comment
> > block starting at line 97), Vybrid requires writing a one for clearing
> > an interrupt flag. Syncing the method for clearing I2SR_IIF in
> > i2c_imx_isr().
> >
> > Signed-off-by: Christian Eggers
> > Fixes: 4b775022f6fd ("i2c: imx: add struct to hold more configurable
> > quirks")
> > Reviewed-by: Uwe Kleine-König
> > Acked-by: Oleksij Rempel
> > Cc: sta...@vger.kernel.org
>
> Applied to for-next, thanks!
>
I cannot find my patches in kernel/git/wsa/linux.git, branch "for-next".
Did they get lost?
regards
Christian
Re: [PATCH v5 2/3] net: add kcov handle to skb extensions
On Mon, Nov 30, 2020 at 05:52:48PM -0800, Jakub Kicinski wrote: > On Sat, 21 Nov 2020 18:09:41 +0200 Ido Schimmel wrote: > > + Florian > > > > On Thu, Oct 29, 2020 at 05:36:19PM +, Aleksandr Nogikh wrote: > > > From: Aleksandr Nogikh > > > > > > Remote KCOV coverage collection enables coverage-guided fuzzing of the > > > code that is not reachable during normal system call execution. It is > > > especially helpful for fuzzing networking subsystems, where it is > > > common to perform packet handling in separate work queues even for the > > > packets that originated directly from the user space. > > > > > > Enable coverage-guided frame injection by adding kcov remote handle to > > > skb extensions. Default initialization in __alloc_skb and > > > __build_skb_around ensures that no socket buffer that was generated > > > during a system call will be missed. > > > > > > Code that is of interest and that performs packet processing should be > > > annotated with kcov_remote_start()/kcov_remote_stop(). > > > > > > An alternative approach is to determine kcov_handle solely on the > > > basis of the device/interface that received the specific socket > > > buffer. However, in this case it would be impossible to distinguish > > > between packets that originated during normal background network > > > processes or were intentionally injected from the user space. > > > > > > Signed-off-by: Aleksandr Nogikh > > > Acked-by: Willem de Bruijn > > > > [...] > > > > > @@ -249,6 +249,9 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t > > > gfp_mask, > > > > > > fclones->skb2.fclone = SKB_FCLONE_CLONE; > > > } > > > + > > > + skb_set_kcov_handle(skb, kcov_common_handle()); > > > > Hi, > > > > This causes skb extensions to be allocated for the allocated skb, but > > there are instances that blindly overwrite 'skb->extensions' by invoking > > skb_copy_header() after __alloc_skb(). For example, skb_copy(), > > __pskb_copy_fclone() and skb_copy_expand(). This results in the skb > > extensions being leaked [1]. > > > > One possible solution is to try to patch all these instances with > > skb_ext_put() before skb_copy_header(). > > > > Another possible solution is to convert skb_copy_header() to use > > skb_ext_copy() instead of __skb_ext_copy(). It will first drop the > > reference on the skb extensions of the new skb, but it assumes that > > 'skb->active_extensions' is valid. This is not the case in the > > skb_clone() path so we should probably zero this field in __skb_clone(). > > > > Other suggestions? > > Looking at the patch from Marco to move back to a field now I'm > wondering how you run into this, Ido :D > > AFAIU the extension is only added if process as a KCOV handle. > > Are you using KCOV? Hi Jakub, Yes. We have an internal syzkaller instance where this is enabled. See "syz-executor.0" in the trace below. > > > [1] > > BUG: memory leak > > unreferenced object 0x888027f9a490 (size 16): > > comm "syz-executor.0", pid 1155, jiffies 4295996826 (age 66.927s) > > hex dump (first 16 bytes): > > 01 00 00 00 01 02 6b 6b 01 00 00 00 00 00 00 00 ..kk > > backtrace: > > [<05a5f2c4>] kmemleak_alloc_recursive > > include/linux/kmemleak.h:43 [inline] > > [<05a5f2c4>] slab_post_alloc_hook mm/slab.h:528 [inline] > > [<05a5f2c4>] slab_alloc_node mm/slub.c:2891 [inline] > > [<05a5f2c4>] slab_alloc mm/slub.c:2899 [inline] > > [<05a5f2c4>] kmem_cache_alloc+0x173/0x800 mm/slub.c:2904 > > [] __skb_ext_alloc+0x22/0x90 net/core/skbuff.c:6173 > > [<0de35e81>] skb_ext_add+0x230/0x4a0 net/core/skbuff.c:6268 > > [<3b7efba4>] skb_set_kcov_handle include/linux/skbuff.h:4622 > > [inline] > > [<3b7efba4>] skb_set_kcov_handle include/linux/skbuff.h:4612 > > [inline] > > [<3b7efba4>] __alloc_skb+0x47f/0x6a0 net/core/skbuff.c:253 > > [<7f789b23>] skb_copy+0x151/0x310 net/core/skbuff.c:1512 > > [<1ce26864>] mlxsw_emad_transmit+0x4e/0x620 > > drivers/net/ethernet/mellanox/mlxsw/core.c:585 > > [<5c732123>] mlxsw_emad_reg_access > > drivers/net/ethernet/mellanox/mlxsw/core.c:829 [inline] > > [<5c732123>] mlxsw_core_reg_access_emad+0xda8/0x1770 > > drivers/net/ethernet/mellanox/mlxsw/core.c:2408 > > [ ] mlxsw_core_reg_access+0x101/0x7f0 > > drivers/net/ethernet/mellanox/mlxsw/core.c:2583 > > [<7c47f30f>] mlxsw_reg_write+0x30/0x40 > > drivers/net/ethernet/mellanox/mlxsw/core.c:2603 > > [<675e3fc7>] mlxsw_sp_port_admin_status_set+0x8a7/0x980 > > drivers/net/ethernet/mellanox/mlxsw/spectrum.c:300 > > [ ] mlxsw_sp_port_stop+0x63/0x70 > > drivers/net/ethernet/mellanox/mlxsw/spectrum.c:537 > > [ ] __dev_close_many+0x1c7/0x300 net/core/dev.c:1607 > > [<628c5987>] __dev_close net/core/dev.c:1619 [inline] >
fs/ext4/fast_commit.c:1753:27: warning: unused function 'tag2str'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b65054597872ce3aefbc6a666385eabdf9e288da
commit: 8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 ext4: fast commit recovery path
date: 6 weeks ago
config: mips-randconfig-r023-20201201 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ac40a2d8f16b8a8c68fc811d67f647740e965cb8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> fs/ext4/fast_commit.c:1753:27: warning: unused function 'tag2str'
static inline const char tag)
^
fatal error: error in backend: Nested variants found in inline asm string: '
.set push
.set mips64r2
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/bitops.h",
.line = 133, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2;
.rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $1
and $0, $2
sc $0, $1
beqz $0, 1b
.set pop
'
clang-12: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 12.0.0 (git://gitmirror/llvm_project
ac40a2d8f16b8a8c68fc811d67f647740e965cb8)
Target: mips-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-ac40a2d8f1/bin
clang-12: note: diagnostic msg:
Makefile arch fs include kernel scripts source usr
vim +/tag2str +1753 fs/ext4/fast_commit.c
1752
> 1753 static inline const char *tag2str(u16 tag)
1754 {
1755 switch (tag) {
1756 case EXT4_FC_TAG_LINK:
1757 return "TAG_ADD_ENTRY";
1758 case EXT4_FC_TAG_UNLINK:
1759 return "TAG_DEL_ENTRY";
1760 case EXT4_FC_TAG_ADD_RANGE:
1761 return "TAG_ADD_RANGE";
1762 case EXT4_FC_TAG_CREAT:
1763 return "TAG_CREAT_DENTRY";
1764 case EXT4_FC_TAG_DEL_RANGE:
1765 return "TAG_DEL_RANGE";
1766 case EXT4_FC_TAG_INODE:
1767 return "TAG_INODE";
1768 case EXT4_FC_TAG_PAD:
1769 return "TAG_PAD";
1770 case EXT4_FC_TAG_TAIL:
1771 return "TAG_TAIL";
1772 case EXT4_FC_TAG_HEAD:
1773 return "TAG_HEAD";
1774 default:
1775 return "TAG_ERROR";
1776 }
1777 }
1778
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 5/5] minor: kunit: tool: s/get_absolute_path/test_data_path in unit test
On Tue, Dec 1, 2020 at 7:33 AM Daniel Latypov wrote: > > 1. the name is a lie. It gives relative paths, e.g. if I run from the > same dir as the test file, it gives './test_data/' > > 2. it's only used for generating paths to tools/testing/kunit/test_data/ > So we can tersen things by making it less general. > > Signed-off-by: Daniel Latypov > --- This is an excellent and overdue rename/replacement. My only note is re: the concerns I have in patch 2, where I think we probably ought to make this function actually return an absolute path. It seems from the code (and the function name) that that was the intent, so if we can fix it, that'd be ideal. Personally, though, I'd still prefer the new test_data_path(), just have it be an actually absolute path. -- David
Re: [PATCH 4/5] kunit: tool: use `with open()` in unit test
On Tue, Dec 1, 2020 at 7:33 AM Daniel Latypov wrote: > > The use of manual open() and .close() calls seems to be an attempt to > keep the contents in scope. > But Python doesn't restrict variables like that, so we can introduce new > variables inside of a `with` and use them outside. > > Do so to make the code more Pythonic. > > Signed-off-by: Daniel Latypov > --- I'm fine with this, and it clearly works fine for me. Out of curiosity, though, is there any difference here other than it being more usual Python style? We've struggled a bit in the past toeing a line between trying to follow "normal" Python style versus adapting it a bit to be more "kernel-y". Experience thus far has actually been that going out on our own has caused more problems than it solves, so I'm all for this change, but I do admit that my brain does understand the older code a touch more easily. In any case, Reviewed-by: David Gow -- David
Re: [PATCH 2/5] kunit: tool: fix unit test so it can run from non-root dir
On Tue, Dec 1, 2020 at 7:33 AM Daniel Latypov wrote:
>
> get_absolute_path() makes an attempt to allow for this.
> But that doesn't work as soon as os.chdir() gets called.
Can we explain why this doesn't work? It's because the test_data/
files are accessed with relative paths, so chdir breaks access to
them, right?
>
> So make it so that os.chdir() does nothing to avoid this.
>
> Note: mock.patch.object() doesn't seem to work in setUpModule(), hence
> the introduction of a new base class instead.
>
> Fixes: 5578d008d9e0 ("kunit: tool: fix running kunit_tool from outside kernel
> tree")
> Signed-off-by: Daniel Latypov
> ---
I don't like this: disabling a real system call seems like overkill to
work around a path issue like this.
Wouldn't it be better to either:
(a) stop kunit_tool from needing to chdir entirely; or
(b) have get_absolute_path() / test_data_path() produce an absolute path.
The latter really seems like the most sensible approach: have the
script read its own path and read files relative to that.
Cheers,
-- David
> tools/testing/kunit/kunit_tool_test.py | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/kunit/kunit_tool_test.py
> b/tools/testing/kunit/kunit_tool_test.py
> index 3fbe1acd531a..9f1f1e1b772a 100755
> --- a/tools/testing/kunit/kunit_tool_test.py
> +++ b/tools/testing/kunit/kunit_tool_test.py
> @@ -32,7 +32,13 @@ def tearDownModule():
> def get_absolute_path(path):
> return os.path.join(os.path.dirname(__file__), path)
>
> -class KconfigTest(unittest.TestCase):
> +class KUnitTest(unittest.TestCase):
> + """Contains common setup, like stopping main() from calling chdir."""
> + def setUp(self):
> + mock.patch.object(os, 'chdir').start()
> + self.addCleanup(mock.patch.stopall)
> +
> +class KconfigTest(KUnitTest):
>
> def test_is_subset_of(self):
> kconfig0 = kunit_config.Kconfig()
> @@ -88,7 +94,7 @@ class KconfigTest(unittest.TestCase):
> self.assertEqual(actual_kconfig.entries(),
> expected_kconfig.entries())
>
> -class KUnitParserTest(unittest.TestCase):
> +class KUnitParserTest(KUnitTest):
>
> def assertContains(self, needle, haystack):
> for line in haystack:
> @@ -250,7 +256,7 @@ class KUnitParserTest(unittest.TestCase):
> result.status)
> self.assertEqual('kunit-resource-test',
> result.suites[0].name)
>
> -class KUnitJsonTest(unittest.TestCase):
> +class KUnitJsonTest(KUnitTest):
>
> def _json_for(self, log_file):
> with(open(get_absolute_path(log_file))) as file:
> @@ -285,8 +291,9 @@ class StrContains(str):
> def __eq__(self, other):
> return self in other
>
> -class KUnitMainTest(unittest.TestCase):
> +class KUnitMainTest(KUnitTest):
> def setUp(self):
> + super().setUp()
> path =
> get_absolute_path('test_data/test_is_test_passed-all_passed.log')
> with open(path) as file:
> all_passed_log = file.readlines()
> --
> 2.29.2.454.gaff20da3a2-goog
>
Re: [PATCH 3/5] kunit: tool: stop using bare asserts in unit test
On Tue, Dec 1, 2020 at 7:33 AM Daniel Latypov wrote: > > Use self.assertEqual/assertNotEqual() instead. > Besides being more appropriate in a unit test, it'll also give a better > error message by show the unexpected values. > > Also > * Delete redundant check of exception types. self.assertRaises does this. > * s/kall/call. There's no reason to name it this way. > * This is probably a misunderstanding from the docs which uses it > since `mock.call` is in scope as `call`. > > Signed-off-by: Daniel Latypov > --- This works for me, and seems pretty sensible from my rudimentary python knowledge. Reviewed-by: David Gow Cheers, -- David
Re: [PATCH 1/5] kunit: tool: fix unit test cleanup handling
On Tue, Dec 1, 2020 at 7:32 AM Daniel Latypov wrote:
>
> * Stop leaking file objects.
> * Use self.addCleanup() to ensure we call cleanup functions even if
> setUp() fails.
> * use mock.patch.stopall instead of more error-prone manual approach
>
> Signed-off-by: Daniel Latypov
> ---
I won't pretend to be an expert on Python, but this seems good to me.
I tested it on my machine and it works fine.
So,
Reviewed-by: David Gow
-- Davkd
> tools/testing/kunit/kunit_tool_test.py | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/kunit/kunit_tool_test.py
> b/tools/testing/kunit/kunit_tool_test.py
> index 497ab51bc170..3fbe1acd531a 100755
> --- a/tools/testing/kunit/kunit_tool_test.py
> +++ b/tools/testing/kunit/kunit_tool_test.py
> @@ -288,19 +288,17 @@ class StrContains(str):
> class KUnitMainTest(unittest.TestCase):
> def setUp(self):
> path =
> get_absolute_path('test_data/test_is_test_passed-all_passed.log')
> - file = open(path)
> - all_passed_log = file.readlines()
> - self.print_patch = mock.patch('builtins.print')
> - self.print_mock = self.print_patch.start()
> + with open(path) as file:
> + all_passed_log = file.readlines()
> +
> + self.print_mock = mock.patch('builtins.print').start()
> + self.addCleanup(mock.patch.stopall)
> +
> self.linux_source_mock = mock.Mock()
> self.linux_source_mock.build_reconfig =
> mock.Mock(return_value=True)
> self.linux_source_mock.build_um_kernel =
> mock.Mock(return_value=True)
> self.linux_source_mock.run_kernel =
> mock.Mock(return_value=all_passed_log)
>
> - def tearDown(self):
> - self.print_patch.stop()
> - pass
> -
> def test_config_passes_args_pass(self):
> kunit.main(['config', '--build_dir=.kunit'],
> self.linux_source_mock)
> assert self.linux_source_mock.build_reconfig.call_count == 1
>
> base-commit: b65054597872ce3aefbc6a666385eabdf9e288da
> --
> 2.29.2.454.gaff20da3a2-goog
>
Re: [PATCH] ARM: dts: OMAP3: disable AES on N950/N9
* Aaro Koskinen [201129 16:47]: > AES needs to be disabled on Nokia N950/N9 as well (HS devices), otherwise > kernel fails to boot. Thanks applying into fixes. Tony
Re: [PATCH] ARM: omap2plus_defconfig: drop unused POWER_AVS option
* Andrey Zhizhikin [201130 14:43]:
> Commit 785b5bb41b0a ("PM: AVS: Drop the avs directory and the
> corresponding Kconfig") moved AVS code to SOC-specific folders, and
> removed corresponding Kconfig from drivers/power, leaving original
> POWER_AVS config option enabled in omap2plus_defconfig file.
>
> Remove the option, which has no references in the tree anymore.
>
> Fixes: 785b5bb41b0a ("PM: AVS: Drop the avs directory and the corresponding
> Kconfig")
Applying into omap-for-v5.11/defconfig-take2 thanks.
Regards,
Tony
[PATCH v4 3/5] ARM: dts: add Kverneland UT1, UT1Q and UT1P
VICUT1(Q,P) is the Kverneland UT1(Q,P) IsoBus universal terminal for
agricultural
applications on tractors.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile| 3 +
arch/arm/boot/dts/imx6dl-vicut1.dts | 13 +
arch/arm/boot/dts/imx6q-vicut1.dts| 17 +
arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 802 ++
arch/arm/boot/dts/imx6qp-vicutp.dts | 13 +
5 files changed, 848 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-vicut1.dts
create mode 100644 arch/arm/boot/dts/imx6q-vicut1.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-vicut1.dtsi
create mode 100644 arch/arm/boot/dts/imx6qp-vicutp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ee725aebc3a8..b6dac6839c0e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -485,6 +485,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-tx6u-811x.dtb \
imx6dl-tx6u-81xx-mb7.dtb \
imx6dl-udoo.dtb \
+ imx6dl-vicut1.dtb \
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
imx6dl-wandboard-revd1.dtb \
@@ -578,6 +579,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-udoo.dtb \
imx6q-utilite-pro.dtb \
imx6q-var-dt6customboard.dtb \
+ imx6q-vicut1.dtb \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb \
imx6q-wandboard-revd1.dtb \
@@ -592,6 +594,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6qp-tx6qp-8037-mb7.dtb \
imx6qp-tx6qp-8137.dtb \
imx6qp-tx6qp-8137-mb7.dtb \
+ imx6qp-vicutp.dtb \
imx6qp-wandboard-revd1.dtb \
imx6qp-zii-rdu2.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
diff --git a/arch/arm/boot/dts/imx6dl-vicut1.dts
b/arch/arm/boot/dts/imx6dl-vicut1.dts
new file mode 100644
index ..174fd913bf96
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-vicut1.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-vicut1.dtsi"
+
+/ {
+ model = "Kverneland UT1 Board";
+ compatible = "kvg,vicut1", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-vicut1.dts
b/arch/arm/boot/dts/imx6q-vicut1.dts
new file mode 100644
index ..0a4e251be162
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-vicut1.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-vicut1.dtsi"
+
+/ {
+ model = "Kverneland UT1Q Board";
+ compatible = "kvg,vicut1q", "fsl,imx6q";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
new file mode 100644
index ..d2eb58a884b1
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
@@ -0,0 +1,802 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ chosen {
+ stdout-path =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ pwms = < 0 500 0>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <1>;
+ power-supply = <_3v3>;
+ enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ connector {
+ compatible = "composite-video-connector";
+ label = "Composite0";
+ sdtv-standards = ;
+
+ port {
+ comp0_out: endpoint {
+ remote-endpoint = <_comp0_in>;
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ power {
+ label = "Power Button";
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ linux,code = <116>; /* KEY_POWER */
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-0 {
+ label = "LED_DI0_DEBUG_0";
+ function = LED_FUNCTION_HEARTBEAT;
+ gpios = < 16 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "LED_DI0_DEBUG_1";
+ function = LED_FUNCTION_DISK;
+ gpios = < 17 GPIO_ACTIVE_HIGH>;
+
[PATCH v4 5/5] ARM: dts: add Kverneland TGO board
VICTGO is the Kverneland TGO IsoBus universal terminal for agricultural
applications on tractors
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-victgo.dts | 850
2 files changed, 851 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-victgo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b6dac6839c0e..b309420975a9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -485,6 +485,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-tx6u-811x.dtb \
imx6dl-tx6u-81xx-mb7.dtb \
imx6dl-udoo.dtb \
+ imx6dl-victgo.dtb \
imx6dl-vicut1.dtb \
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-victgo.dts
b/arch/arm/boot/dts/imx6dl-victgo.dts
new file mode 100644
index ..636f98274f08
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-victgo.dts
@@ -0,0 +1,850 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Kverneland TGO";
+ compatible = "kvg,victgo", "fsl,imx6dl";
+
+ chosen {
+ stdout-path =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ pwms = < 0 500 0>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <1>;
+ power-supply = <_3v3>;
+ enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ connector {
+ compatible = "composite-video-connector";
+ label = "Composite0";
+ sdtv-standards = ;
+
+ port {
+ comp0_out: endpoint {
+ remote-endpoint = <_comp0_in>;
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpiokeys>;
+ autorepeat;
+
+ power {
+ label = "Power Button";
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ linux,code = <116>; /* KEY_POWER */
+ wakeup-source;
+ };
+
+ enter {
+ label = "Rotary Key";
+ gpios = < 05 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-0 {
+ label = "debug0";
+ function = LED_FUNCTION_HEARTBEAT;
+ gpios = < 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "debug1";
+ function = LED_FUNCTION_DISK;
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+
+ led-2 {
+ label = "power_led";
+ function = LED_FUNCTION_POWER;
+ gpios = < 24 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ panel {
+ compatible = "kyo,tcg121xglp";
+ backlight = <>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt =
Re: [PATCH 0/2] ARM: dts: am335x-evm/evmsk/icev2: switch to new cpsw switch drv
* Grygorii Strashko [201119 17:45]: > Hi Tony, > > This is the initial conversation of am335x boards to use new cpsw switch > driver. > This series adds the cpsw switch driver DT definition and > am335x-evm/evmsk/icev2 > boards are converted to use it. Thanks applying into omap-for-v5.11/dt. Regards, Tony
[PATCH v4 1/5] dt-bindings: vendor-prefixes: Add an entry for Kverneland Group
Add "kvg" entry for Kverneland Group: https://ien.kvernelandgroup.com/ Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 8332d50301ea..7da549f508ae 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -567,6 +567,8 @@ patternProperties: description: Sutajio Ko-Usagi PTE Ltd. "^kyo,.*": description: Kyocera Corporation + "^kvg,.*": +description: Kverneland Group "^lacie,.*": description: LaCie "^laird,.*": -- 2.29.2
[PATCH v4 4/5] dt-bindings: arm: fsl: add Kverneland TGO board
Add Kverneland TGO imx6dl based board Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 7b2f83bb56cb..8abe71b8646d 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -366,6 +366,7 @@ properties: - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - kvg,victgo# Kverneland TGO - kvg,vicut1# Kverneland UT1 board - ply,plybas# Plymovent BAS board - ply,plym2m# Plymovent M2M board -- 2.29.2
Re: [PATCH] hwmon: corsair-psu: update supported devices
On Mon, 30 Nov 2020 18:25:30 +0200 Backlund Thomas wrote: > Den 30.11.2020 kl. 16:49, skrev Wilken Gottwalt: > > On Mon, 30 Nov 2020 14:43:44 +0200 > > Thomas Backlund wrote: > > > >> Den 28.11.2020 kl. 12:35, skrev Wilken Gottwalt: > >>> On Sat, 28 Nov 2020 02:37:38 -0300 > >>> Jonas Malaco wrote: > >>> > On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt > wrote: > > Adds support for another Corsair PSUs series: AX760i, AX860i, AX1200i, > > AX1500i and AX1600i. The first 3 power supplies are supported through > > the Corsair Link USB Dongle which is some kind of USB/Serial/TTL > > converter especially made for the COM ports of these power supplies. > > There are 3 known revisions of these adapters. The AX1500i power supply > > has revision 3 built into the case and AX1600i is the only one in that > > series, which has an unique usb hid id like the RM/RX series. > Can I ask what AXi power supplies were tested? > > I ask because, based on the user-space implementations I am aware of, > the AXi dongle protocol appears to be different from the RMi/HXi series. > >>> I was not able to test this against the AX power supplies, they are really > >>> hard to find (and are far to expensive). But I went through all these > >>> tools > >>> and stuck to the most common commands, which all 3 series support. Not > >>> every > >>> series supports all commands (there also seem to be different firmwares in > >>> the micro-conrollers). But this is fine, some sensors will show up as N/A. > >>> Even my HX850i does not support all commands covered in this driver. > >>> > >> What kind of tests do you want / need ? > >> > >> I have an AX860i here. > > Oh nice. Lets start with an usb info dump. Can you give me the full dump of > > lsusb -vd of the Corsair USB dongle? > > $ lsusb -vd 1b1c:1c00 > > Bus 011 Device 005: ID 1b1c:1c00 Corsair Controller for Corsair Link > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x1b1c Corsair > idProduct 0x1c00 Controller for Corsair Link > bcdDevice 1.00 > iManufacturer 1 Silicon Labs > iProduct 2 Corsair Link TM USB Dongle > iSerial 3 R7480347 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0020 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 2 Corsair Link TM USB Dongle > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > can't get debug descriptor: Resource temporarily unavailable > Device Status: 0x > (Bus Powered) Thank you. Hmm yeah, this dongle has no usb hid part. So this driver will not work with this dongle for sure. I already have an idea how to support all 3 series, though it involves a lot of testing. I would provide a github repo with tools and test kernel modules if you are interested. But I don't know yet how long it will take, I work on other stuff which has a higher prio. greetings, Wilken > -- > > Thomas > >
[PATCH v4 2/5] dt-bindings: arm: fsl: add Kverneland UT1, UT1Q and UI1P boards
Add Kverneland UT1 (imx6dl), UT1Q (imx6q) and UT1P (imx6dp) based boards Signed-off-by: Oleksij Rempel --- Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 490cbc75b18a..7b2f83bb56cb 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -210,6 +210,7 @@ properties: - kiebackpeter,imx6q-tpc# K+P i.MX6 Quad TPC Board - kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module - kosagi,imx6q-novena # Kosagi Novena Dual/Quad + - kvg,vicut1q # Kverneland UT1Q board - logicpd,imx6q-logicpd - lwn,display5 # Liebherr Display5 i.MX6 Quad Board - lwn,mccmon6 # Liebherr Monitor6 i.MX6 Quad Board @@ -331,6 +332,7 @@ properties: - fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board - fsl,imx6qp-sabresd# i.MX6 Quad Plus SABRE Smart Device Board - karo,imx6qp-tx6qp # Ka-Ro electronics TX6QP-8037 Module + - kvg,vicutp# Kverneland UT1P board - prt,prtwd3# Protonic WD3 board - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board @@ -364,6 +366,7 @@ properties: - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - kvg,vicut1# Kverneland UT1 board - ply,plybas# Plymovent BAS board - ply,plym2m# Plymovent M2M board - poslab,imx6dl-savageboard # Poslab SavageBoard Dual -- 2.29.2
[PATCH v4 0/5] mainline Kverneland boards
changes v4: - fix active level of SPI CS GPIOs changes v3: - add vicutp board - change tvnorm to sdtv-standards - change linux,default-trigger "mmc" to "disk-activity"; - add power-supply property to the panel node changes v2: - add victgo board - diff fixes for vicut1.dtsi Oleksij Rempel (5): dt-bindings: vendor-prefixes: Add an entry for Kverneland Group dt-bindings: arm: fsl: add Kverneland UT1, UT1Q and UI1P boards ARM: dts: add Kverneland UT1, UT1Q and UT1P dt-bindings: arm: fsl: add Kverneland TGO board ARM: dts: add Kverneland TGO board .../devicetree/bindings/arm/fsl.yaml | 4 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 4 + arch/arm/boot/dts/imx6dl-victgo.dts | 850 ++ arch/arm/boot/dts/imx6dl-vicut1.dts | 13 + arch/arm/boot/dts/imx6q-vicut1.dts| 17 + arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 802 + arch/arm/boot/dts/imx6qp-vicutp.dts | 13 + 8 files changed, 1705 insertions(+) create mode 100644 arch/arm/boot/dts/imx6dl-victgo.dts create mode 100644 arch/arm/boot/dts/imx6dl-vicut1.dts create mode 100644 arch/arm/boot/dts/imx6q-vicut1.dts create mode 100644 arch/arm/boot/dts/imx6qdl-vicut1.dtsi create mode 100644 arch/arm/boot/dts/imx6qp-vicutp.dts -- 2.29.2
[PATCH v2] checkpatch: fix TYPO_SPELLING check for words with apostrophe
checkpatch reports a false TYPO_SPELLING warning for some words
containing an apostrophe when run with --codespell option.
A false positive is "doesn't". Occurrence of the word causes
checkpatch to emit the following warning:
"WARNING: 'doesn'' may be misspelled - perhaps 'doesn't'?"
Modify the regex pattern to be more in line with the codespell
default word matching regex. This fixes the word capture and
avoids the false warning.
Suggested-by: Joe Perches
Reported-by: Peilin Ye
Signed-off-by: Dwaipayan Ray
---
Changes in v2:
- Use the default codespell word regex.
- Modify commit message to specify --codespell usage
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3c86ea737e9c..bd6304f93e0a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3106,7 +3106,7 @@ sub process {
# Check for various typo / spelling mistakes
if (defined($misspellings) &&
($in_commit_log || $line =~ /^(?:\+|Subject:)/i)) {
- while ($rawline =~
/(?:^|[^a-z@])($misspellings)(?:\b|$|[^a-z@])/gi) {
+ while ($rawline =~
/(?:^|[^\w\-'`])($misspellings)(?:[^\w\-'`]|$)/gi) {
my $typo = $1;
my $typo_fix = $spelling_fix{lc($typo)};
$typo_fix = ucfirst($typo_fix) if ($typo =~
/^[A-Z]/);
--
2.27.0
Re: [RFC PATCH 1/3] KVM: arm64: Fix possible memory leak in kvm stage2
Hi Will, On 2020/11/30 21:21, Will Deacon wrote: On Mon, Nov 30, 2020 at 08:18:45PM +0800, Yanan Wang wrote: When installing a new leaf pte onto an invalid ptep, we need to get_page(ptep). When just updating a valid leaf ptep, we shouldn't get_page(ptep). Incorrect page_count of translation tables might lead to memory leak, when unmapping a stage 2 memory range. Did you find this by inspection, or did you hit this in practice? I'd be interested to see the backtrace for mapping over an existing mapping. Actually this is found by inspection. In the current code, get_page() will uniformly called at "out_get_page" in function stage2_map_walk_leaf(), no matter the old ptep is valid or not. When using stage2_unmap_walker() API to unmap a memory range, some page-table pages might not be freed if page_count of the pages is not right. Signed-off-by: Yanan Wang --- arch/arm64/kvm/hyp/pgtable.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c index 0271b4a3b9fe..696b6aa83faf 100644 --- a/arch/arm64/kvm/hyp/pgtable.c +++ b/arch/arm64/kvm/hyp/pgtable.c @@ -186,6 +186,7 @@ static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa, kvm_pte_t attr, return old == pte; smp_store_release(ptep, pte); + get_page(virt_to_page(ptep)); This is also used for the hypervisor stage-1 page-table, so I'd prefer to leave this function as-is. I agree at this point. return true; } @@ -476,6 +477,7 @@ static bool stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level, /* There's an existing valid leaf entry, so perform break-before-make */ kvm_set_invalid_pte(ptep); kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, data->mmu, addr, level); + put_page(virt_to_page(ptep)); kvm_set_valid_leaf_pte(ptep, phys, data->attr, level); out: data->phys += granule; Isn't this hunk alone sufficient to solve the problem? Will . Not sufficient enough. When the old ptep is valid and old pte equlas new pte, in this case, "True" is also returned by kvm_set_valid_leaf_pte() and get_page() will still be called. Yanan
Re: [PATCH v5 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
Hello Jonathan,
very nice driver, just a few minor comments below.
On Tue, Dec 01, 2020 at 02:15:10AM +0100, Jonathan Neuschäfer wrote:
> +static struct ntxec_pwm *pwmchip_to_priv(struct pwm_chip *chip)
a function prefix would be great here, I'd pick ntxec_pwm_from_chip as
name.
> +{
> + return container_of(chip, struct ntxec_pwm, chip);
> +}
> +
> +[...]
> +static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm_dev,
> +const struct pwm_state *state)
> +{
> + struct ntxec_pwm *priv = pwmchip_to_priv(pwm_dev->chip);
> + unsigned int period, duty;
> + struct reg_sequence regs[] = {
> + { NTXEC_REG_PERIOD_HIGH },
> + { NTXEC_REG_PERIOD_LOW },
> + { NTXEC_REG_DUTY_HIGH },
> + { NTXEC_REG_DUTY_LOW }
> + };
> + int res;
> +
> + if (state->polarity != PWM_POLARITY_NORMAL)
> + return -EINVAL;
> +
> + period = min_t(u64, state->period, MAX_PERIOD_NS);
> + duty = min_t(u64, state->duty_cycle, period);
I'm not a big fan of aligning =. (As if you have to add a longer
variable you have to realign all otherwise unrelated lines.) But that's
subjective and it's up to you if you want to change this.
> + period /= TIME_BASE_NS;
> + duty /= TIME_BASE_NS;
> +
> + /*
> + * Changes to the period and duty cycle take effect as soon as the
> + * corresponding low byte is written, so the hardware may be configured
> + * to an inconsistent state after the period is written and before the
> + * duty cycle is fully written. If, in such a case, the old duty cycle
> + * is longer than the new period, the EC may output 100% for a moment.
> + */
> +
> + regs[0].def = ntxec_reg8(period >> 8);
> + regs[1].def = ntxec_reg8(period);
> + regs[2].def = ntxec_reg8(duty >> 8);
> + regs[3].def = ntxec_reg8(duty);
You could even minimize the window by changing the order here to
NTXEC_REG_PERIOD_HIGH
NTXEC_REG_DUTY_HIGH
NTXEC_REG_PERIOD_LOW
NTXEC_REG_DUTY_LOW
but it gets less readable. Maybe move that to a function to have the
reg_sequence and the actual write nearer together? Or somehow name the
indexes to make it more obvious?
> + res = regmap_multi_reg_write(priv->ec->regmap, regs, ARRAY_SIZE(regs));
> + if (res)
> + return res;
> +
> + /*
> + * Writing a duty cycle of zero puts the device into a state where
> + * writing a higher duty cycle doesn't result in the brightness that it
> + * usually results in. This can be fixed by cycling the ENABLE register.
> + *
> + * As a workaround, write ENABLE=0 when the duty cycle is zero.
If the device already has duty_cycle = 0 but ENABLE = 1, you might get
a failure. But I guess this doesn't need addressing in the code. But
maybe point it out in a comment?
> + */
> + if (state->enabled && duty != 0) {
> + res = regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE,
> ntxec_reg8(1));
> + if (res)
> + return res;
> +
> + /* Disable the auto-off timer */
> + res = regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_HI,
> ntxec_reg8(0xff));
> + if (res)
> + return res;
> +
> + return regmap_write(priv->ec->regmap, NTXEC_REG_AUTO_OFF_LO,
> ntxec_reg8(0xff));
Given that you cannot read back period and duty anyhow: Does it make
sense to write these only if (state->enabled && duty != 0)?
> + } else {
> + return regmap_write(priv->ec->regmap, NTXEC_REG_ENABLE,
> ntxec_reg8(0));
> + }
> +}
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH] INPUT: xpad: support Ardwiino Controllers
From: Sanjay Govind
This commit adds support for Ardwiino Controllers
Signed-off-by: Sanjay Govind
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index c77cdb3b62b5..91a5c7e7bdd2 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -245,6 +245,7 @@ static const struct xpad_device {
{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0303, "Mortal Kombat Klassic FightStick",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX
},
+ { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
{ 0x1430, 0x4748, "RedOctane Guitar Hero X-plorer", 0, XTYPE_XBOX360 },
{ 0x1430, 0x, "TX6500+ Dance Pad (first generation)",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
@@ -418,6 +419,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x0f0d),/* Hori Controllers */
XPAD_XBOX360_VENDOR(0x1038),/* SteelSeries Controllers */
XPAD_XBOX360_VENDOR(0x11c9),/* Nacon GC100XF */
+ XPAD_XBOX360_VENDOR(0x1209),/* Ardwiino Controllers */
XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360
controllers */
XPAD_XBOX360_VENDOR(0x146b),/* BigBen Interactive
Controllers */
--
2.29.2
Re: [PATCH 32/40] drm/amd/display/amdgpu_dm/amdgpu_dm: Mark 'link_bandwidth_kbps' as __maybe_unused
On Mon, 30 Nov 2020, Alex Deucher wrote: > On Thu, Nov 26, 2020 at 8:43 AM Lee Jones wrote: > > > > 'link_bandwidth_kbps' is always obtained, but only used if > > CONFIG_DRM_AMD_DC_DCN is defined. > > Probably better to just move this under CONFIG_DRM_AMD_DC_DCN. I'll > send a patch. I considered that, but thought there would have been good reason for the clause break just for dc_link_bandwidth_kbps(). -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v5 6/7] MAINTAINERS: Add entry for Netronix embedded controller
Let's make sure I'll notice when there are patches for the NTXEC drivers. Signed-off-by: Jonathan Neuschäfer --- v4, v5: - no changes v3: - https://lore.kernel.org/lkml/20200924192455.2484005-7-j.neuschae...@gmx.net/ - Remove pwm and rtc bindings v2: - https://lore.kernel.org/lkml/20200905144503.1067124-2-j.neuschae...@gmx.net/ - No changes --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee673f7f..9eedf3c1e1e09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12087,6 +12087,15 @@ F: include/net/netrom.h F: include/uapi/linux/netrom.h F: net/netrom/ +NETRONIX EMBEDDED CONTROLLER +M: Jonathan Neuschäfer +S: Maintained +F: Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +F: drivers/mfd/ntxec.c +F: drivers/pwm/pwm-ntxec.c +F: drivers/rtc/rtc-ntxec.c +F: include/linux/mfd/ntxec.h + NETRONOME ETHERNET DRIVERS M: Simon Horman R: Jakub Kicinski -- 2.29.2
[PATCH v2] f2fs: Remove unnecessary unlikely()
From: Yangtao Li
WARN_ON() already contains an unlikely(), so it's not necessary
to use unlikely.
Signed-off-by: Yangtao Li
Signed-off-by: Shuosheng Huang
---
v2:
add Signed-off-by
---
fs/f2fs/f2fs.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..9f33a508fe51 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -33,10 +33,8 @@
#else
#define f2fs_bug_on(sbi, condition)\
do {\
- if (unlikely(condition)) { \
- WARN_ON(1); \
+ if (WARN_ON(condition)) \
set_sbi_flag(sbi, SBI_NEED_FSCK); \
- } \
} while (0)
#endif
--
2.28.0
Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open
On 11/30/20, Jiri Slaby wrote: > The difference to other control flags is that open raises DTR/RTS in any > case (i.e. including O_NONBLOCK) Yes, this is the exact root-cause problem I am trying to fix, with Johan's help. > -- provided baud rate is set (and it is > for casual serials). That means you cannot open a port to configure it > (using e.g. setserial) without actually raising the DTR/RTS. Exactly. M~
Re: [PATCH] INPUT: xpad: support Ardwiino Controllers
Hi Sanjay,
On Tue, Dec 01, 2020 at 07:48:45PM +1300, sanjay.govi...@gmail.com wrote:
> From: Sanjay Govind
>
> This commit adds support for Ardwiino Controllers
Thank you for resending the patch, it now is formatted properly. However
I believe you need to also add information about Ardwiino controllers to
xpad_device table so that they are properly identified by the kernel.
Thanks.
>
> Signed-off-by: Sanjay Govind
> ---
> drivers/input/joystick/xpad.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index c77cdb3b62b5..c9d78e2acb38 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -418,6 +418,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOXONE_VENDOR(0x0f0d),/* Hori Controllers */
> XPAD_XBOX360_VENDOR(0x1038),/* SteelSeries Controllers */
> XPAD_XBOX360_VENDOR(0x11c9),/* Nacon GC100XF */
> + XPAD_XBOX360_VENDOR(0x1209),/* Ardwiino Controllers */
> XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
> XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360
> controllers */
> XPAD_XBOX360_VENDOR(0x146b),/* BigBen Interactive
> Controllers */
> --
> 2.29.2
>
--
Dmitry
[PATCH v3] lib: Convert test_hexdump.c to KUnit
Convert test lib/test_hexdump.c to KUnit. More information about
KUnit can be found at:
https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html.
KUnit provides a common framework for unit tests in the kernel.
KUnit and kselftest are standardizing around KTAP, converting this
test to KUnit makes this test output in KTAP which we are trying to
make the standard test result format for the kernel.
I ran both the original and converted tests as is to produce the
output for success of the test in the two cases. I also ran these
tests with a small modification to show the difference in the output
for failure of the test in both cases. The modification I made is:
static const char * const test_data_4_le[] __initconst = {
- "7bdb32be", "b293180a", "24c4ba70", "9b34837d",
+ "7bdb32be", "b293180a", "24c4ba70", "9b3483d",
The difference in outputs can be seen here:
https://gist.github.com/arpi-r/38f53a3c65692bf684a6bf3453884b6e
Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
---
Changes v2->v3:
- Modify KUNIT_EXPECT macros used
- kunittest variable made static
- A more detailed commit message
Changes v1->v2:
- Replace KUNIT_EXPECT_EQ() with KUNIT_EXPECT_EQ_MSG()
- Replace KUNIT_EXPECT_NE() with KUNIT_EXPECT_NE_MSG()
- Prints expected and real buffer values in case of test failure
lib/Kconfig.debug | 7 ++-
lib/Makefile| 2 +-
lib/{test_hexdump.c => hexdump_kunit.c} | 73 +++--
3 files changed, 36 insertions(+), 46 deletions(-)
rename lib/{test_hexdump.c => hexdump_kunit.c} (78%)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c789b39ed527..a82ff23b19e7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2039,9 +2039,6 @@ config ASYNC_RAID6_TEST
If unsure, say N.
-config TEST_HEXDUMP
- tristate "Test functions located in the hexdump module at runtime"
-
config TEST_STRING_HELPERS
tristate "Test functions located in the string_helpers module at
runtime"
@@ -2280,6 +2277,10 @@ config BITS_TEST
If unsure, say N.
+config HEXDUMP_KUNIT_TEST
+ tristate "KUnit test for functions located in the hexdump module at
runtime"
+ depends on KUNIT
+
config TEST_UDELAY
tristate "udelay test driver"
help
diff --git a/lib/Makefile b/lib/Makefile
index dc76e7d8a453..f046ecf2817a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_STRING_SELFTEST) += test_string.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += hexdump.o
-obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
obj-y += kstrtox.o
obj-$(CONFIG_FIND_BIT_BENCHMARK) += find_bit_benchmark.o
obj-$(CONFIG_TEST_BPF) += test_bpf.o
@@ -352,3 +351,4 @@ obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
obj-$(CONFIG_BITS_TEST) += bits_kunit.o
obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
+obj-$(CONFIG_HEXDUMP_KUNIT_TEST) += hexdump_kunit.o
diff --git a/lib/test_hexdump.c b/lib/hexdump_kunit.c
similarity index 78%
rename from lib/test_hexdump.c
rename to lib/hexdump_kunit.c
index 5144899d3c6b..c12f3229485c 100644
--- a/lib/test_hexdump.c
+++ b/lib/hexdump_kunit.c
@@ -3,6 +3,7 @@
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -61,12 +62,11 @@ static const char * const test_data_8_be[] __initconst = {
#define FILL_CHAR '#'
-static unsigned total_tests __initdata;
-static unsigned failed_tests __initdata;
+static struct kunit *kunittest;
-static void __init test_hexdump_prepare_test(size_t len, int rowsize,
-int groupsize, char *test,
-size_t testlen, bool ascii)
+static void test_hexdump_prepare_test(size_t len, int rowsize,
+ int groupsize, char *test,
+ size_t testlen, bool ascii)
{
char *p;
const char * const *result;
@@ -122,14 +122,12 @@ static void __init test_hexdump_prepare_test(size_t len,
int rowsize,
#define TEST_HEXDUMP_BUF_SIZE (32 * 3 + 2 + 32 + 1)
-static void __init test_hexdump(size_t len, int rowsize, int groupsize,
- bool ascii)
+static void test_hexdump(size_t len, int rowsize, int groupsize,
+bool ascii)
{
char test[TEST_HEXDUMP_BUF_SIZE];
char real[TEST_HEXDUMP_BUF_SIZE];
- total_tests++;
-
memset(real, FILL_CHAR, sizeof(real));
hex_dump_to_buffer(data_b, len, rowsize, groupsize, real, sizeof(real),
ascii);
@@ -138,15 +136,12 @@ static void __init test_hexdump(size_t len, int rowsize,
int groupsize,
test_hexdump_prepare_test(len, rowsize, groupsize, test, sizeof(test),
ascii);
- if (memcmp(test, real, TEST_HEXDUMP_BUF_SIZE))
Re: [PATCH 1/5] tty: add port flag to suppress ready signalling on open
On 01. 12. 20, 8:09, Mychaela Falconia wrote: On 11/30/20, Jiri Slaby wrote: port can be const here. [...] We have assign_bit() for these cases these days. Johan's patch adding test and set accessor inline functions for the new flag follows the style of the existing accessor inline functions for previously existing flags, for the sake of consistency. If we are going to use the new style (const for test functions, assign_bit() for set functions) for the new flag, then we should also change all existing ones for consistency. In terms of patch splitting, would it be most kosher to have one patch that updates the style of existing accessor inline functions, and then the interesting patch that adds the new flag? Yes. Or the other way around. Add this new using const+assign_bit and convert the rest on the top of the series. thanks, -- js
Re: [PATCH] input: raydium_ts_i2c: Do not split tx transactions
On Mon, Nov 30, 2020 at 11:06 PM Dmitry Torokhov wrote: > > On Mon, Nov 30, 2020 at 10:54:46PM -0800, Furquan Shaikh wrote: > > Hello Dmitry, > > > > On Mon, Nov 30, 2020 at 10:28 PM Dmitry Torokhov > > wrote: > > > > > > Hi Furquan, > > > > > > On Mon, Nov 30, 2020 at 10:00:50PM -0800, Furquan Shaikh wrote: > > > > Raydium device does not like splitting of tx transactions into > > > > multiple messages - one for the register address and one for the > > > > actual data. This results in incorrect behavior on the device side. > > > > > > > > This change updates raydium_i2c_read and raydium_i2c_write to create > > > > i2c_msg arrays separately and passes those arrays into > > > > raydium_i2c_xfer which decides based on the address whether the bank > > > > switch command should be sent. The bank switch header is still added > > > > by raydium_i2c_read and raydium_i2c_write to ensure that all these > > > > operations are performed as part of a single I2C transfer. It > > > > guarantees that no other transactions are initiated to any other > > > > device on the same bus after the bank switch command is sent. > > > > > > i2c_transfer locks the bus [segment] for the entire time, so this > > > explanation on why the change is needed does not make sense. > > > > The actual problem is with raydium_i2c_write chopping off the write > > data into 2 messages -- one for register address and other for actual > > data. Raydium devices do not like that. Hence, this change to ensure > > that the register address and actual data are packaged into a single > > message. The latter part of the above comment attempts to explain why > > the bank switch message is added to xfer[] array in raydium_i2c_read > > and raydium_i2c_write instead of sending a separate message in > > raydium_i2c_xfer i.e. to ensure that the read/write xfer and bank > > switch are sent to i2c_transfer as a single array of messages so that > > they can be handled as an atomic operation from the perspective of > > communication with this device on the bus. > > OK, I see. > > > > > > > > > Also, does it help if you mark the data message as I2C_M_NOSTART in case > > > of writes? > > > > That is a great suggestion. I think this would be helpful in this > > scenario. Let me follow-up on this to see if it helps with the current > > problem. > > > > > > > > I also wonder if we should convert the driver to regmap, which should > > > help with handling the bank switch as well as figuring out if it can do > > > "gather write" or fall back to allocating an additional send buffer. > > > > I will start with the above suggestion and fallback to this if that > > doesn't work. > > So my understanding is that not all I2C adapters support I2C_M_NOSTART > so that is why regmap is nice as it hides it all away and figures things > on its own. > > So simple solution of I2C_M_NOSTART might be a quick fix for Chrome OS > kernel, but we'd either need to always use more expensive 2nd buffer as > is in your patch, or regmap. Ah I see. That makes sense. In that case, I think switching to regmap would be better. As you suggested, I can use I2C_M_NOSTART as a quick fix and work on enabling regmap. > > Thanks. > > -- > Dmitry
Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open
On 30. 11. 20, 22:22, Mychaela Falconia wrote: 2) For situations in which the luxury of a custom USB ID is not available, e.g., a situation where the device that does not tolerate automatic DTR/RTS assertion on open is a physical RS-232 device that can be connected to "any" serial port, the new sysfs attribute comes to the rescue. Johan's patch comments say that the new flag can also be brought out to termios in the future, similarly to HUPCL, The difference to other control flags is that open raises DTR/RTS in any case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is for casual serials). That means you cannot open a port to configure it (using e.g. setserial) without actually raising the DTR/RTS. but I question the usefulness of doing so, as it is a chicken and egg problem: one needs to open the tty device in order to do termios ioctls on it, and if that initial open triggers DTR/RTS hardware actions, then the end user is still screwed. If Johan or someone else can see a potential use case for manipulating this new flag via termios (as opposed to sysfs or USB-ID-based driver quirks), perhaps you could elaborate on it? We would need to (ab)use another open flag (e.g. O_DIRECT). I am not biased to either of solutions. thanks, -- js
[RFC PATCH 2/2] nvme: add simple copy support
Add support for TP 4065a ("Simple Copy Command"), v2020.05.04
("Ratified")
The implementation uses the payload passed from the block layer
to form simple copy command. Set the device copy limits to queue
limits.
Signed-off-by: SelvaKumar S
Signed-off-by: Kanchan Joshi
Signed-off-by: Nitesh Shetty
Signed-off-by: Javier González
---
drivers/nvme/host/core.c | 91
drivers/nvme/host/nvme.h | 4 ++
include/linux/nvme.h | 45 ++--
3 files changed, 136 insertions(+), 4 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 9b6ebeb29cca..eb6a3157cb2b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -647,6 +647,65 @@ static inline void nvme_setup_flush(struct nvme_ns *ns,
cmnd->common.nsid = cpu_to_le32(ns->head->ns_id);
}
+static inline blk_status_t nvme_setup_copy(struct nvme_ns *ns,
+ struct request *req, struct nvme_command *cmnd)
+{
+ struct nvme_ctrl *ctrl = ns->ctrl;
+ struct nvme_copy_range *range = NULL;
+ struct blk_copy_payload *payload;
+ u16 control = 0;
+ u32 dsmgmt = 0;
+ int nr_range = 0, i;
+ u16 ssrl;
+ u64 slba;
+
+ payload = bio_data(req->bio);
+ nr_range = payload->copy_range;
+
+ if (req->cmd_flags & REQ_FUA)
+ control |= NVME_RW_FUA;
+
+ if (req->cmd_flags & REQ_FAILFAST_DEV)
+ control |= NVME_RW_LR;
+
+ cmnd->copy.opcode = nvme_cmd_copy;
+ cmnd->copy.nsid = cpu_to_le32(ns->head->ns_id);
+ cmnd->copy.sdlba = cpu_to_le64(blk_rq_pos(req) >> (ns->lba_shift - 9));
+
+ range = kmalloc_array(nr_range, sizeof(*range),
+ GFP_ATOMIC | __GFP_NOWARN);
+ if (!range)
+ return BLK_STS_RESOURCE;
+
+ for (i = 0; i < nr_range; i++) {
+ slba = payload->range[i].src;
+ slba = slba >> (ns->lba_shift - 9);
+
+ ssrl = payload->range[i].len;
+ ssrl = ssrl >> (ns->lba_shift - 9);
+
+ range[i].slba = cpu_to_le64(slba);
+ range[i].nlb = cpu_to_le16(ssrl - 1);
+ }
+
+ cmnd->copy.nr_range = nr_range - 1;
+
+ req->special_vec.bv_page = virt_to_page(range);
+ req->special_vec.bv_offset = offset_in_page(range);
+ req->special_vec.bv_len = sizeof(*range) * nr_range;
+ req->rq_flags |= RQF_SPECIAL_PAYLOAD;
+
+ if (ctrl->nr_streams)
+ nvme_assign_write_stream(ctrl, req, , );
+
+ //TBD end-to-end
+
+ cmnd->rw.control = cpu_to_le16(control);
+ cmnd->rw.dsmgmt = cpu_to_le32(dsmgmt);
+
+ return BLK_STS_OK;
+}
+
static blk_status_t nvme_setup_discard(struct nvme_ns *ns, struct request *req,
struct nvme_command *cmnd)
{
@@ -829,6 +888,9 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
request *req,
case REQ_OP_DISCARD:
ret = nvme_setup_discard(ns, req, cmd);
break;
+ case REQ_OP_COPY:
+ ret = nvme_setup_copy(ns, req, cmd);
+ break;
case REQ_OP_READ:
ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_read);
break;
@@ -1850,6 +1912,32 @@ static void nvme_config_discard(struct gendisk *disk,
struct nvme_ns *ns)
blk_queue_max_write_zeroes_sectors(queue, UINT_MAX);
}
+static void nvme_config_copy(struct gendisk *disk, struct nvme_ns *ns,
+ struct nvme_id_ns *id)
+{
+ struct nvme_ctrl *ctrl = ns->ctrl;
+ struct request_queue *queue = disk->queue;
+
+ if (!(ctrl->oncs & NVME_CTRL_ONCS_COPY)) {
+ queue->limits.max_copy_sectors = 0;
+ blk_queue_flag_clear(QUEUE_FLAG_COPY, queue);
+ return;
+ }
+
+ /* setting copy limits */
+ ns->mcl = le64_to_cpu(id->mcl);
+ ns->mssrl = le32_to_cpu(id->mssrl);
+ ns->msrc = id->msrc;
+
+ if (blk_queue_flag_test_and_set(QUEUE_FLAG_COPY, queue))
+ return;
+
+ queue->limits.max_copy_sectors = ns->mcl * (1 << (ns->lba_shift - 9));
+ queue->limits.max_copy_range_sectors = ns->mssrl *
+ (1 << (ns->lba_shift - 9));
+ queue->limits.max_copy_nr_ranges = ns->msrc + 1;
+}
+
static void nvme_config_write_zeroes(struct gendisk *disk, struct nvme_ns *ns)
{
u64 max_blocks;
@@ -2045,6 +2133,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
set_capacity_and_notify(disk, capacity);
nvme_config_discard(disk, ns);
+ nvme_config_copy(disk, ns, id);
nvme_config_write_zeroes(disk, ns);
if (id->nsattr & NVME_NS_ATTR_RO)
@@ -3014,6 +3103,7 @@ int nvme_init_identify(struct nvme_ctrl *ctrl)
ctrl->oaes = le32_to_cpu(id->oaes);
ctrl->wctemp = le16_to_cpu(id->wctemp);
ctrl->cctemp = le16_to_cpu(id->cctemp);
+ ctrl->ocfs = le32_to_cpu(id->ocfs);
[RFC PATCH 1/2] block: add simple copy support
Add new BLKCOPY ioctl that offloads copying of multiple sources
to a destination to the device. Accept copy_ranges that contains
destination, no of sources and pointer to the array of source
ranges. Each range_entry contains start and length of source
ranges (in bytes).
Introduce REQ_OP_COPY, a no-merge copy offload operation. Create
bio with control information as payload and submit to the device.
REQ_OP_COPY(19) is a write op and takes zone_write_lock when submitted
to zoned device.
Introduce queue limits for simple copy and other helper functions.
Add device limits as sysfs entries.
- max_copy_sectors
- max_copy_ranges_sectors
- max_copy_nr_ranges
max_copy_sectors = 0 indicates the device doesn't support copy.
Signed-off-by: SelvaKumar S
Signed-off-by: Kanchan Joshi
Signed-off-by: Nitesh Shetty
Signed-off-by: Javier González
---
block/blk-core.c | 104 +++---
block/blk-lib.c | 116 ++
block/blk-merge.c | 2 +
block/blk-settings.c | 11
block/blk-sysfs.c | 23
block/blk-zoned.c | 1 +
block/bounce.c| 1 +
block/ioctl.c | 43 ++
include/linux/bio.h | 1 +
include/linux/blk_types.h | 7 +++
include/linux/blkdev.h| 15 +
include/uapi/linux/fs.h | 21 +++
12 files changed, 337 insertions(+), 8 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 2db8bda43b6e..6818d0cdf627 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -719,6 +719,17 @@ static noinline int should_fail_bio(struct bio *bio)
}
ALLOW_ERROR_INJECTION(should_fail_bio, ERRNO);
+static inline int bio_check_copy_eod(struct bio *bio, sector_t start,
+ sector_t nr_sectors, sector_t maxsector)
+{
+ if (nr_sectors && maxsector && (nr_sectors > maxsector ||
+ start > maxsector - nr_sectors)) {
+ handle_bad_sector(bio, maxsector);
+ return -EIO;
+ }
+ return 0;
+}
+
/*
* Check whether this bio extends beyond the end of the device or partition.
* This may well happen - the kernel calls bread() without checking the size of
@@ -737,6 +748,75 @@ static inline int bio_check_eod(struct bio *bio, sector_t
maxsector)
return 0;
}
+/*
+ * Check for copy limits and remap source ranges if needed.
+ */
+static inline int blk_check_copy(struct bio *bio)
+{
+ struct hd_struct *p = NULL;
+ struct request_queue *q = bio->bi_disk->queue;
+ struct blk_copy_payload *payload;
+ unsigned short nr_range;
+ int ret = -EIO;
+ int i, copy_len = 0;
+
+ rcu_read_lock();
+
+ if (bio->bi_partno) {
+ p = __disk_get_part(bio->bi_disk, bio->bi_partno);
+ if (unlikely(!p))
+ goto out;
+ if (unlikely(bio_check_ro(bio, p)))
+ goto out;
+ } else {
+ if (unlikely(bio_check_ro(bio, >bi_disk->part0)))
+ goto out;
+ }
+
+ payload = bio_data(bio);
+ nr_range = payload->copy_range;
+
+ /* cannot handle copy crossing nr_ranges limit */
+ if (payload->copy_range > q->limits.max_copy_nr_ranges)
+ goto out;
+
+ for (i = 0; i < nr_range; i++) {
+ copy_len += payload->range[i].len;
+ if (p) {
+ if (bio_check_copy_eod(bio, payload->range[i].src,
+ payload->range[i].len,
part_nr_sects_read(p)))
+ goto out;
+ payload->range[i].src += p->start_sect;
+ } else {
+ if (unlikely(bio_check_copy_eod(bio,
payload->range[i].src,
+ payload->range[i].len,
+ get_capacity(bio->bi_disk
+ goto out;
+ }
+ }
+
+ /* cannot handle copy more than copy limits */
+ if (copy_len > q->limits.max_copy_sectors)
+ goto out;
+
+ if (p) {
+ if (unlikely(bio_check_copy_eod(bio, bio->bi_iter.bi_sector,
copy_len,
+ part_nr_sects_read(p
+ goto out;
+ } else {
+ if (unlikely(bio_check_copy_eod(bio, bio->bi_iter.bi_sector,
copy_len,
+ get_capacity(bio->bi_disk
+ goto out;
+
+ }
+
+ if (p)
+ bio->bi_partno = 0;
+ ret = 0;
+out:
+ rcu_read_unlock();
+ return ret;
+}
/*
* Remap block n of partition p to block n+start(p) of the disk.
*/
@@ -825,14 +905,16 @@ static noinline_for_stack bool submit_bio_checks(struct
bio *bio)
if (should_fail_bio(bio))
goto end_io;
- if (bio->bi_partno) {
-
[RFC PATCH 0/2] add simple copy support
This patchset tries to add support for TP4065a ("Simple Copy Command"),
v2020.05.04 ("Ratified")
The Specification can be found in following link.
https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
This is an RFC. Looking forward for any feedbacks or other alternate
designs for plumbing simple copy to IO stack.
Simple copy command is a copy offloading operation and is used to copy
multiple contiguous ranges (source_ranges) of LBA's to a single destination
LBA within the device reducing traffic between host and device.
This implementation accepts destination, no of sources and arrays of
source ranges from application and attach it as payload to the bio and
submits to the device.
Following limits are added to queue limits and are exposed in sysfs
to userspace
- *max_copy_sectors* limits the sum of all source_range length
- *max_copy_nr_ranges* limits the number of source ranges
- *max_copy_range_sectors* limit the maximum number of sectors
that can constitute a single source range.
SelvaKumar S (2):
block: add simple copy support
nvme: add simple copy support
block/blk-core.c | 104 +++---
block/blk-lib.c | 116 ++
block/blk-merge.c | 2 +
block/blk-settings.c | 11
block/blk-sysfs.c | 23
block/blk-zoned.c | 1 +
block/bounce.c| 1 +
block/ioctl.c | 43 ++
drivers/nvme/host/core.c | 91 ++
drivers/nvme/host/nvme.h | 4 ++
include/linux/bio.h | 1 +
include/linux/blk_types.h | 7 +++
include/linux/blkdev.h| 15 +
include/linux/nvme.h | 45 +--
include/uapi/linux/fs.h | 21 +++
15 files changed, 473 insertions(+), 12 deletions(-)
--
2.25.1
Re: [PATCH 10/18] ipu3-cio2: Rename ipu3-cio2.c to allow module to be built from multiple source files retaining ipu3-cio2 name
On 12/1/20 2:56 PM, Bingbu Cao wrote:
> I see there will be multiple files, but there will be no conflict if keep as
> the main
> file name unchanged, right? If so, I prefer keep as it was.
Oops, I notice you try to build all the files into single module, so please
ignore my
comment above.
>
> On 11/30/20 9:31 PM, Daniel Scally wrote:
>> ipu3-cio2 driver needs extending with multiple files; rename the main
>> source file and specify the renamed file in Makefile to accommodate that.
>>
>> Suggested-by: Andy Shevchenko
>> Reviewed-by: Andy Shevchenko
>> Reviewed-by: Laurent Pinchart
>> Signed-off-by: Daniel Scally
>> ---
>> Changes since RFC v3:
>>
>> - None
>>
>> drivers/media/pci/intel/ipu3/Makefile | 2 ++
>> drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} | 0
>> 2 files changed, 2 insertions(+)
>> rename drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} (100%)
>>
>> diff --git a/drivers/media/pci/intel/ipu3/Makefile
>> b/drivers/media/pci/intel/ipu3/Makefile
>> index 98ddd5beafe0..429d516452e4 100644
>> --- a/drivers/media/pci/intel/ipu3/Makefile
>> +++ b/drivers/media/pci/intel/ipu3/Makefile
>> @@ -1,2 +1,4 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>> +
>> +ipu3-cio2-y += ipu3-cio2-main.o
>> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
>> b/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>> similarity index 100%
>> rename from drivers/media/pci/intel/ipu3/ipu3-cio2.c
>> rename to drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>>
>
--
Best regards,
Bingbu Cao
Re: [PATCH v1 2/2] ARM: dts: add Protonic MVT board
On Mon, Nov 30, 2020 at 10:22:38AM -0300, Fabio Estevam wrote:
> Hi Oleksij,
>
> On Mon, Nov 30, 2020 at 10:14 AM Oleksij Rempel
> wrote:
>
> > + {
> > + cs-gpios = < 19 GPIO_ACTIVE_HIGH>;
>
> Shouldn't this be GPIO_ACTIVE_LOW instead?
ACK, it was fixed up by this code:
https://elixir.bootlin.com/linux/v5.10-rc6/source/drivers/gpio/gpiolib-of.c#L210
So, it was still working.
Thank you! I'll fix it.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 1/5] tty: add port flag to suppress ready signalling on open
On 11/30/20, Jiri Slaby wrote: > port can be const here. > [...] > We have assign_bit() for these cases these days. Johan's patch adding test and set accessor inline functions for the new flag follows the style of the existing accessor inline functions for previously existing flags, for the sake of consistency. If we are going to use the new style (const for test functions, assign_bit() for set functions) for the new flag, then we should also change all existing ones for consistency. In terms of patch splitting, would it be most kosher to have one patch that updates the style of existing accessor inline functions, and then the interesting patch that adds the new flag? M~
Re: [PATCH] input: raydium_ts_i2c: Do not split tx transactions
On Mon, Nov 30, 2020 at 10:54:46PM -0800, Furquan Shaikh wrote: > Hello Dmitry, > > On Mon, Nov 30, 2020 at 10:28 PM Dmitry Torokhov > wrote: > > > > Hi Furquan, > > > > On Mon, Nov 30, 2020 at 10:00:50PM -0800, Furquan Shaikh wrote: > > > Raydium device does not like splitting of tx transactions into > > > multiple messages - one for the register address and one for the > > > actual data. This results in incorrect behavior on the device side. > > > > > > This change updates raydium_i2c_read and raydium_i2c_write to create > > > i2c_msg arrays separately and passes those arrays into > > > raydium_i2c_xfer which decides based on the address whether the bank > > > switch command should be sent. The bank switch header is still added > > > by raydium_i2c_read and raydium_i2c_write to ensure that all these > > > operations are performed as part of a single I2C transfer. It > > > guarantees that no other transactions are initiated to any other > > > device on the same bus after the bank switch command is sent. > > > > i2c_transfer locks the bus [segment] for the entire time, so this > > explanation on why the change is needed does not make sense. > > The actual problem is with raydium_i2c_write chopping off the write > data into 2 messages -- one for register address and other for actual > data. Raydium devices do not like that. Hence, this change to ensure > that the register address and actual data are packaged into a single > message. The latter part of the above comment attempts to explain why > the bank switch message is added to xfer[] array in raydium_i2c_read > and raydium_i2c_write instead of sending a separate message in > raydium_i2c_xfer i.e. to ensure that the read/write xfer and bank > switch are sent to i2c_transfer as a single array of messages so that > they can be handled as an atomic operation from the perspective of > communication with this device on the bus. OK, I see. > > > > > Also, does it help if you mark the data message as I2C_M_NOSTART in case > > of writes? > > That is a great suggestion. I think this would be helpful in this > scenario. Let me follow-up on this to see if it helps with the current > problem. > > > > > I also wonder if we should convert the driver to regmap, which should > > help with handling the bank switch as well as figuring out if it can do > > "gather write" or fall back to allocating an additional send buffer. > > I will start with the above suggestion and fallback to this if that > doesn't work. So my understanding is that not all I2C adapters support I2C_M_NOSTART so that is why regmap is nice as it hides it all away and figures things on its own. So simple solution of I2C_M_NOSTART might be a quick fix for Chrome OS kernel, but we'd either need to always use more expensive 2nd buffer as is in your patch, or regmap. Thanks. -- Dmitry
[PATCH] bus: mhi: core: Fix error handling in mhi_register_controller()
There are a few problems with the error handling in this function. They
mostly center around the alloc_ordered_workqueue() allocation.
1) If that allocation fails or if the kcalloc() prior to it fails then
it leads to a NULL dereference when we call
destroy_workqueue(mhi_cntrl->hiprio_wq).
2) The error code is not set.
3) The "mhi_cntrl->mhi_cmd" allocation is not freed.
The error handling was slightly confusing and I re-ordered it to be in
the exact mirror/reverse order of how things were allocated. I changed
the label names to say what the goto does instead of describing where
the goto comes from.
Fixes: 8f7039787687 ("bus: mhi: core: Move to using high priority workqueue")
Signed-off-by: Dan Carpenter
---
drivers/bus/mhi/core/init.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 96cde9c0034c..f0697f433c2f 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -871,7 +871,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
sizeof(*mhi_cntrl->mhi_cmd), GFP_KERNEL);
if (!mhi_cntrl->mhi_cmd) {
ret = -ENOMEM;
- goto error_alloc_cmd;
+ goto err_free_event;
}
INIT_LIST_HEAD(_cntrl->transition_list);
@@ -886,7 +886,8 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
("mhi_hiprio_wq", WQ_MEM_RECLAIM | WQ_HIGHPRI);
if (!mhi_cntrl->hiprio_wq) {
dev_err(mhi_cntrl->cntrl_dev, "Failed to allocate workqueue\n");
- goto error_alloc_cmd;
+ ret = -ENOMEM;
+ goto err_free_cmd;
}
mhi_cmd = mhi_cntrl->mhi_cmd;
@@ -932,7 +933,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
ret = mhi_read_reg(mhi_cntrl, mhi_cntrl->regs,
SOC_HW_VERSION_OFFS, _info);
if (ret)
- goto error_alloc_dev;
+ goto err_destroy_wq;
mhi_cntrl->family_number = (soc_info & SOC_HW_VERSION_FAM_NUM_BMSK) >>
SOC_HW_VERSION_FAM_NUM_SHFT;
@@ -946,7 +947,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
mhi_cntrl->index = ida_alloc(_controller_ida, GFP_KERNEL);
if (mhi_cntrl->index < 0) {
ret = mhi_cntrl->index;
- goto error_ida_alloc;
+ goto err_destroy_wq;
}
/* Register controller with MHI bus */
@@ -954,7 +955,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
if (IS_ERR(mhi_dev)) {
dev_err(mhi_cntrl->cntrl_dev, "Failed to allocate MHI
device\n");
ret = PTR_ERR(mhi_dev);
- goto error_alloc_dev;
+ goto err_ida_free;
}
mhi_dev->dev_type = MHI_DEVICE_CONTROLLER;
@@ -967,7 +968,7 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
ret = device_add(_dev->dev);
if (ret)
- goto error_add_dev;
+ goto err_release_dev;
mhi_cntrl->mhi_dev = mhi_dev;
@@ -975,19 +976,17 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
return 0;
-error_add_dev:
+err_release_dev:
put_device(_dev->dev);
-
-error_alloc_dev:
+err_ida_free:
ida_free(_controller_ida, mhi_cntrl->index);
-
-error_ida_alloc:
+err_destroy_wq:
+ destroy_workqueue(mhi_cntrl->hiprio_wq);
+err_free_cmd:
kfree(mhi_cntrl->mhi_cmd);
-
-error_alloc_cmd:
- vfree(mhi_cntrl->mhi_chan);
+err_free_event:
kfree(mhi_cntrl->mhi_event);
- destroy_workqueue(mhi_cntrl->hiprio_wq);
+ vfree(mhi_cntrl->mhi_chan);
return ret;
}
--
2.29.2
[PATCH] f2fs: Remove unnecessary unlikely()
From: Yangtao Li
WARN_ON() already contains an unlikely(), so it's not necessary
to use unlikely.
Signed-off-by: Yangtao Li
---
fs/f2fs/f2fs.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..9f33a508fe51 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -33,10 +33,8 @@
#else
#define f2fs_bug_on(sbi, condition)\
do {\
- if (unlikely(condition)) { \
- WARN_ON(1); \
+ if (WARN_ON(condition)) \
set_sbi_flag(sbi, SBI_NEED_FSCK); \
- } \
} while (0)
#endif
--
2.28.0
RE: [PATCH v2] scsi: ufs: Remove pre-defined initial voltage values of device powers
> > UFS specficication allows different VCC configurations for UFS devices, > for example, > (1). 2.70V - 3.60V (Activated by default in UFS core driver) > (2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in > device tree) > (3). 2.40V - 2.70V (Supported since UFS 3.x) > > With the introduction of UFS 3.x products, an issue is happening that > UFS driver will use wrong "min_uV-max_uV" values to configure the > voltage of VCC regulator on UFU 3.x products with the configuration (3) > used. > > To solve this issue, we simply remove pre-defined initial VCC voltage > values in UFS core driver with below reasons, > > 1. UFS specifications do not define how to detect the VCC configuration >supported by attached device. > > 2. Device tree already supports standard regulator properties. > > Therefore VCC voltage shall be defined correctly in device tree, and > shall not changed by UFS driver. What UFS driver needs to do is simply > enable or disable the VCC regulator only. > > Similar change is applied to VCCQ and VCCQ2 as well. > > Note that we keep struct ufs_vreg unchanged. This is allow vendors to > configure proper min_uV and max_uV of any regulators to make > regulator_set_voltage() works during regulator toggling flow. > Without specific vendor configurations, min_uV and max_uV will be NULL > by default and UFS core driver will enable or disable the regulator > only without adjusting its voltage. > > Reviewed-by: Bjorn Andersson > Signed-off-by: Stanley Chu Acked-by: Avri Altman
RE: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values
> > Hi Stanley > > > > Thanks for the patch. Bao (nguyenb) was also working towards > something > > similar. > > Would it be possible for you to take into account the scenario in > which the > > same platform supports both 2.x and 3.x UFS devices? > > > > These've different voltage requirements, 2.4v-3.6v. > > I'm not sure if standard dts regulator properties can support this. > > > > >>> > > >>> What is the actual voltage requirement for these devices and how > does > > >>> the software know what voltage to pick in this range? > > >>> > > >>> Regards, > > >>> Bjorn > > >>> > > -asd > > > > > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code > Aurora Forum, > > Linux Foundation Collaborative Project > > >> > > >> For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the > > >> voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the > > >> ufs device at 2.95v & reads the version and if the device is 3.x, it may > > >> do the following: > > >> - Set the device power mode to SLEEP > > >> - Disable the Vcc > > >> - Enable the Vcc and set it to 2.5v > > >> - Set the device power mode to ACTIVE > > >> > > >> All of the above may be done at HS-G1 & moved to max supported gear > > >> based on the device version, perhaps? > > > > > > Hi Asutosh, > > > > > > Thanks for sharing this idea. > > > > > > 1. I did not see above flow defined in UFS specifications, please > > > correct me if I was wrong. > > > > > > 2. For above flow, the concern is that I am not sure if all devices > > > supporting VCC (2.4v - 2.7v) can accept higher voltage, say 2.95v, for > > > version detection. > > > > > > 3. For version detection, another concern is that I am not sure if all > > > 3.x devices support VCC (2.4v - 2.7v) only, or in other words, I am not > > > sure if all 2.x devices support VCC (2.7v - 3.6v) only. The above rule > > > will break any devices not obeying this "conventions". > > > > > > For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), > > > > > > It would be good for UFS drivers detecting the correct voltage if the > > > protocol is well-defined in specifications. Until that day, any > > > "non-standard" way may be better implemented in vendor's ops? > > > > > > If the vop concept works on your platform, we could still keep struct > > > ufs_vreg and allow vendors to configure proper min_uV and max_uV to > make > > > regulator_set_voltage() works during VCC toggling flow. Without specific > > > vendor configurations, min_uV and max_uV would be NULL by default > and > > > UFS core driver will only enable/disasble VCC regulator only without > > > adjusting its voltage. > > > > > > > I think this would work. Do you plan to implement this? > > If not, I can take this up. Please let me know. > > Thanks for the understanding and support. > > I would like to re-post this patch to simply removing the pre-defined > initial values of all device powers. > > For vop idea supporting the voltage detection way, could you please take > it up since this would be better to fit what you need for fixing this > issue? Again - why vop and not a dts flag? The platform owner is aware of which device ships on which platform, isn't it? Thanks, Avri
Re: [PATCH 10/18] ipu3-cio2: Rename ipu3-cio2.c to allow module to be built from multiple source files retaining ipu3-cio2 name
I see there will be multiple files, but there will be no conflict if keep as
the main
file name unchanged, right? If so, I prefer keep as it was.
On 11/30/20 9:31 PM, Daniel Scally wrote:
> ipu3-cio2 driver needs extending with multiple files; rename the main
> source file and specify the renamed file in Makefile to accommodate that.
>
> Suggested-by: Andy Shevchenko
> Reviewed-by: Andy Shevchenko
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Daniel Scally
> ---
> Changes since RFC v3:
>
> - None
>
> drivers/media/pci/intel/ipu3/Makefile | 2 ++
> drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} | 0
> 2 files changed, 2 insertions(+)
> rename drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} (100%)
>
> diff --git a/drivers/media/pci/intel/ipu3/Makefile
> b/drivers/media/pci/intel/ipu3/Makefile
> index 98ddd5beafe0..429d516452e4 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -1,2 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> +
> +ipu3-cio2-y += ipu3-cio2-main.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> b/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
> similarity index 100%
> rename from drivers/media/pci/intel/ipu3/ipu3-cio2.c
> rename to drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
>
--
Best regards,
Bingbu Cao
Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values
Hi Asutosh,
On Mon, 2020-11-30 at 19:07 -0800, Asutosh Das (asd) wrote:
> On 11/30/2020 5:25 PM, Stanley Chu wrote:
> > On Mon, 2020-11-30 at 15:54 -0800, Asutosh Das (asd) wrote:
> >> On 11/30/2020 3:14 PM, Bjorn Andersson wrote:
> >>> On Mon 30 Nov 16:51 CST 2020, Asutosh Das (asd) wrote:
> >>>
> On 11/30/2020 1:16 AM, Stanley Chu wrote:
> > UFS specficication allows different VCC configurations for UFS devices,
> > for example,
> > (1). 2.70V - 3.60V (By default)
> > (2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
> > device tree)
> > (3). 2.40V - 2.70V (Supported since UFS 3.x)
> >
> > With the introduction of UFS 3.x products, an issue is happening that
> > UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
> > regulator on UFU 3.x products with VCC configuration (3) used.
> >
> > To solve this issue, we simply remove pre-defined initial VCC voltage
> > values in UFS driver with below reasons,
> >
> > 1. UFS specifications do not define how to detect the VCC configuration
> > supported by attached device.
> >
> > 2. Device tree already supports standard regulator properties.
> >
> > Therefore VCC voltage shall be defined correctly in device tree, and
> > shall not be changed by UFS driver. What UFS driver needs to do is
> > simply
> > enabling or disabling the VCC regulator only.
> >
> > This is a RFC conceptional patch. Please help review this and feel
> > free to feedback any ideas. Once this concept is accepted, and then
> > I would post a more completed patch series to fix this issue.
> >
> > Signed-off-by: Stanley Chu
> > ---
> > drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
> > b/drivers/scsi/ufs/ufshcd-pltfrm.c
> > index a6f76399b3ae..3965be03c136 100644
> > --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> > +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> > @@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device
> > *dev, const char *name,
> > vreg->max_uA = 0;
> > }
> > - if (!strcmp(name, "vcc")) {
> > - if (of_property_read_bool(np, "vcc-supply-1p8")) {
> > - vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
> > - vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
> > - } else {
> > - vreg->min_uV = UFS_VREG_VCC_MIN_UV;
> > - vreg->max_uV = UFS_VREG_VCC_MAX_UV;
> > - }
> > - } else if (!strcmp(name, "vccq")) {
> > + if (!strcmp(name, "vccq")) {
> > vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
> > vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
> > } else if (!strcmp(name, "vccq2")) {
> >
>
> Hi Stanley
>
> Thanks for the patch. Bao (nguyenb) was also working towards something
> similar.
> Would it be possible for you to take into account the scenario in which
> the
> same platform supports both 2.x and 3.x UFS devices?
>
> These've different voltage requirements, 2.4v-3.6v.
> I'm not sure if standard dts regulator properties can support this.
>
> >>>
> >>> What is the actual voltage requirement for these devices and how does
> >>> the software know what voltage to pick in this range?
> >>>
> >>> Regards,
> >>> Bjorn
> >>>
> -asd
>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum,
> Linux Foundation Collaborative Project
> >>
> >> For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the
> >> voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the
> >> ufs device at 2.95v & reads the version and if the device is 3.x, it may
> >> do the following:
> >> - Set the device power mode to SLEEP
> >> - Disable the Vcc
> >> - Enable the Vcc and set it to 2.5v
> >> - Set the device power mode to ACTIVE
> >>
> >> All of the above may be done at HS-G1 & moved to max supported gear
> >> based on the device version, perhaps?
> >
> > Hi Asutosh,
> >
> > Thanks for sharing this idea.
> >
> > 1. I did not see above flow defined in UFS specifications, please
> > correct me if I was wrong.
> >
> > 2. For above flow, the concern is that I am not sure if all devices
> > supporting VCC (2.4v - 2.7v) can accept higher voltage, say 2.95v, for
> > version detection.
> >
> > 3. For version detection, another concern is that I am not sure if all
> > 3.x devices support VCC (2.4v - 2.7v) only, or in other words, I am not
> > sure if all 2.x devices support VCC (2.7v - 3.6v) only. The above rule
> > will break any devices not obeying this "conventions".
Re: [PATCH] input: raydium_ts_i2c: Do not split tx transactions
Hello Dmitry, On Mon, Nov 30, 2020 at 10:28 PM Dmitry Torokhov wrote: > > Hi Furquan, > > On Mon, Nov 30, 2020 at 10:00:50PM -0800, Furquan Shaikh wrote: > > Raydium device does not like splitting of tx transactions into > > multiple messages - one for the register address and one for the > > actual data. This results in incorrect behavior on the device side. > > > > This change updates raydium_i2c_read and raydium_i2c_write to create > > i2c_msg arrays separately and passes those arrays into > > raydium_i2c_xfer which decides based on the address whether the bank > > switch command should be sent. The bank switch header is still added > > by raydium_i2c_read and raydium_i2c_write to ensure that all these > > operations are performed as part of a single I2C transfer. It > > guarantees that no other transactions are initiated to any other > > device on the same bus after the bank switch command is sent. > > i2c_transfer locks the bus [segment] for the entire time, so this > explanation on why the change is needed does not make sense. The actual problem is with raydium_i2c_write chopping off the write data into 2 messages -- one for register address and other for actual data. Raydium devices do not like that. Hence, this change to ensure that the register address and actual data are packaged into a single message. The latter part of the above comment attempts to explain why the bank switch message is added to xfer[] array in raydium_i2c_read and raydium_i2c_write instead of sending a separate message in raydium_i2c_xfer i.e. to ensure that the read/write xfer and bank switch are sent to i2c_transfer as a single array of messages so that they can be handled as an atomic operation from the perspective of communication with this device on the bus. > > Also, does it help if you mark the data message as I2C_M_NOSTART in case > of writes? That is a great suggestion. I think this would be helpful in this scenario. Let me follow-up on this to see if it helps with the current problem. > > I also wonder if we should convert the driver to regmap, which should > help with handling the bank switch as well as figuring out if it can do > "gather write" or fall back to allocating an additional send buffer. I will start with the above suggestion and fallback to this if that doesn't work. Thanks for the quick response and the helpful suggestions Dmitry. I will work on these pointers and get back to you. Thanks again. - Furquan > > Thanks. > > -- > Dmitry
Re: [PATCH 5/5] USB: serial: ftdi_sio: add support for FreeCalypso DUART28C adapter
On 30. 11. 20, 16:37, Johan Hovold wrote:
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
...
@@ -2386,6 +2393,21 @@ static int ftdi_stmclite_probe(struct usb_serial *serial)
return 0;
}
+/*
+ * FreeCalypso DUART28C is an FT2232D-based USB to dual UART adapter
+ * with a special quirk: Channel B RTS and DTR outputs (BDBUS2 and BDBUS4
+ * on the chip) have been repurposed to drive PWON and RESET controls.
+ */
+static void ftdi_duart28c_setup(struct usb_serial_port *port)
+{
+ struct usb_serial *serial = port->serial;
+ struct usb_interface *intf = serial->interface;
+ int ifnum = intf->cur_altsetting->desc.bInterfaceNumber;
+
+ if (ifnum == 1)
+ tty_port_set_nordy(>port, 1);
So s/1/true, provided the parameter is defined as bool now.
thanks,
--
js
[PATCH] scsi/NCR5380: Remove in_interrupt() test
The in_interrupt() macro is deprecated. Also, it's usage in NCR5380_poll_politely2() has long been redundant. Cc: Sebastian Andrzej Siewior Cc: Ahmed S. Darwish Cc: Thomas Gleixner Link: https://lore.kernel.org/r/20201126132952.2287996-1-bige...@linutronix.de Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c index 462d911a89f2..6972e7ceb81a 100644 --- a/drivers/scsi/NCR5380.c +++ b/drivers/scsi/NCR5380.c @@ -223,7 +223,10 @@ static int NCR5380_poll_politely2(struct NCR5380_hostdata *hostdata, cpu_relax(); } while (n--); - if (irqs_disabled() || in_interrupt()) + /* Sleeping is not allowed when in atomic or interrupt contexts. +* Callers in such contexts always disable local irqs. +*/ + if (irqs_disabled()) return -ETIMEDOUT; /* Repeatedly sleep for 1 ms until deadline */ -- 2.26.2
[PATCH] crypto: hisilicon/trng replace atomic_add_return()
a set of atomic_inc_return() looks more neater
Signed-off-by: Yejune Deng
---
drivers/crypto/hisilicon/trng/trng.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/trng/trng.c
b/drivers/crypto/hisilicon/trng/trng.c
index a5033cf..2971268 100644
--- a/drivers/crypto/hisilicon/trng/trng.c
+++ b/drivers/crypto/hisilicon/trng/trng.c
@@ -267,12 +267,12 @@ static int hisi_trng_probe(struct platform_device *pdev)
}
hisi_trng_add_to_list(trng);
- if (atomic_add_return(1, _active_devs) == 1) {
+ if (atomic_inc_return(_active_devs) == 1) {
ret = crypto_register_rng(_trng_alg);
if (ret) {
dev_err(>dev,
"failed to register crypto(%d)\n", ret);
- atomic_sub_return(1, _active_devs);
+ atomic_dec_return(_active_devs);
goto err_remove_from_list;
}
}
@@ -289,7 +289,7 @@ static int hisi_trng_probe(struct platform_device *pdev)
return ret;
err_crypto_unregister:
- if (atomic_sub_return(1, _active_devs) == 0)
+ if (atomic_dec_return(_active_devs) == 0)
crypto_unregister_rng(_trng_alg);
err_remove_from_list:
@@ -305,7 +305,7 @@ static int hisi_trng_remove(struct platform_device *pdev)
while (hisi_trng_del_from_list(trng))
;
- if (atomic_sub_return(1, _active_devs) == 0)
+ if (atomic_dec_return(_active_devs) == 0)
crypto_unregister_rng(_trng_alg);
return 0;
--
1.9.1
[PATCH v2] scsi: ufs: Remove pre-defined initial voltage values of device powers
UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (Activated by default in UFS core driver)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)
With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV-max_uV" values to configure the
voltage of VCC regulator on UFU 3.x products with the configuration (3)
used.
To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS core driver with below reasons,
1. UFS specifications do not define how to detect the VCC configuration
supported by attached device.
2. Device tree already supports standard regulator properties.
Therefore VCC voltage shall be defined correctly in device tree, and
shall not changed by UFS driver. What UFS driver needs to do is simply
enable or disable the VCC regulator only.
Similar change is applied to VCCQ and VCCQ2 as well.
Note that we keep struct ufs_vreg unchanged. This is allow vendors to
configure proper min_uV and max_uV of any regulators to make
regulator_set_voltage() works during regulator toggling flow.
Without specific vendor configurations, min_uV and max_uV will be NULL
by default and UFS core driver will enable or disable the regulator
only without adjusting its voltage.
Reviewed-by: Bjorn Andersson
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..09e2f04bf4f6 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,22 +133,6 @@ static int ufshcd_populate_vreg(struct device *dev, const
char *name,
vreg->max_uA = 0;
}
- if (!strcmp(name, "vcc")) {
- if (of_property_read_bool(np, "vcc-supply-1p8")) {
- vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
- vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
- } else {
- vreg->min_uV = UFS_VREG_VCC_MIN_UV;
- vreg->max_uV = UFS_VREG_VCC_MAX_UV;
- }
- } else if (!strcmp(name, "vccq")) {
- vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
- vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
- } else if (!strcmp(name, "vccq2")) {
- vreg->min_uV = UFS_VREG_VCCQ2_MIN_UV;
- vreg->max_uV = UFS_VREG_VCCQ2_MAX_UV;
- }
-
goto out;
out:
--
2.18.0
Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device
Hi Dan,
On Mon, Nov 30, 2020 at 11:06:03PM +, Dan Scally wrote:
> Hi Sakari
>
> On 30/11/2020 20:52, Sakari Ailus wrote:
> >> +static const struct acpi_device_id int3472_device_id[] = {
> >> + { "INT3472", 0 },
> > The INT3472 _HID is really allocated for the tps68470 PMIC chip. It may not
> > be used by other drivers; people will want to build kernels where both of
> > these ACPI table layouts are functional.
> >
> > Instead, I propose, that you add this as an option to the tps68470 driver
> > that figures out whether the ACPI device for the tps68470 device actually
> > describes something else, in a similar fashion you do with the cio2-bridge
> > driver. I think it may need a separate Kconfig option albeit this and
> > cio2-bridge cannot be used separately.
>
> It actually occurs to me that that may not work (I know I called that
> out as an option we considered, but that was a while ago actually). The
> reason I wasn't worried about the existing tps68470 driver binding to
> these devices is that it's an i2c driver, and these dummy devices don't
> have an I2cSerialBusV2, so no I2C device is created by them the kernel.
>
>
> Won't that mean the tps68470 driver won't ever be probed for these devices?
Oops. I missed this indeed was not an I²C driver. So please ignore the
comment.
So I guess this wouldn't be an actual problem. I'd still like to test this
on a system with tps68470, as the rest of the set.
--
Kind regards,
Sakari Ailus
[PATCH] INPUT: xpad: support Ardwiino Controllers
From: Sanjay Govind
This commit adds support for Ardwiino Controllers
Signed-off-by: Sanjay Govind
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index c77cdb3b62b5..c9d78e2acb38 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -418,6 +418,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x0f0d),/* Hori Controllers */
XPAD_XBOX360_VENDOR(0x1038),/* SteelSeries Controllers */
XPAD_XBOX360_VENDOR(0x11c9),/* Nacon GC100XF */
+ XPAD_XBOX360_VENDOR(0x1209),/* Ardwiino Controllers */
XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360
controllers */
XPAD_XBOX360_VENDOR(0x146b),/* BigBen Interactive
Controllers */
--
2.29.2
Re: linux-next: build failure after merge of the phy-next tree
Hi Stephen,
On Tue, Dec 1, 2020 at 7:07 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the phy-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/phy/ralink/phy-mt7621-pci.c:17:10: fatal error: mt7621.h: No such
> file or directory
>17 | #include
> | ^~
>
> Caused by commit
>
> d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY")
This driver has two includes which are in
"arch/mips/include/asm/mach-ralink" and are directly included in the
driver:
* mt7621.h
* ralink_regs.h
This is because this path is directly included in
arch/mips/ralink/Platform for "ralink":
#
# Ralink SoC common stuff
#
cflags-$(CONFIG_RALINK) += -I$(srctree)/arch/mips/include/asm/mach-ralink
and this driver directly depends on RALINK or COMPILE_TEST (which
might be the problem here):
and this driver directly depends
on RALINK or COMPILE_TEST:
config PHY_MT7621_PCI
tristate "MediaTek MT7621 PCI PHY Driver"
depends on (RALINK || COMPILE_TEST) && OF
select GENERIC_PHY
select REGMAP_MMIO
help
Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver
>
> I have reverted that commit for today.
What is the correct way of fixing this? Include complete path for both
of them like this?
index db79088d5362..cebd53f5a797 100644
--- a/drivers/phy/ralink/phy-mt7621-pci.c
+++ b/drivers/phy/ralink/phy-mt7621-pci.c
@@ -14,8 +14,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
Vinod, please let me know if you want me to send anything for fixing this.
>
> --
> Cheers,
> Stephen Rothwell
Best regards,
Sergio Paracuellos
Re: [PATCH V6] kthread: Add debugobject support
Hi,tglx
Would you like to continue to review the new patch set?I made some
changes according to your suggestion.
Unless this change will not be considered or unnecessary.
Thanks
Qianli Zhao 于2020年10月12日周一 上午11:00写道：
>
> From: Qianli Zhao
>
> kthread_work is not covered by debug objects, but the same problems as with
> regular work objects apply.
>
> Some of the issues like reinitialization of an active kthread_work are hard
> to debug because the problem manifests itself later in a completely
> different context.
>
> Add debugobject support along with the necessary fixup functions to make
> debugging of these problems less tedious.
>
> Signed-off-by: Qianli Zhao
> ---
> V6:
> - Changelog update follow tglx's suggestion
> - Completion initialized as part of kthread_init_work_onstack() in
> kthread_flush_worker()/kthread_flush_work()
>
> V5:
> - Fix format error checked by checkpatch.pl
>
> V4:
> - Changelog update
> - Add comment for KWORK_ENTRY_STATIC
> - Code format modification
> - Check worker availability early in kthread_flush_work
>
> V3:
> - changelog update
> - add fixup_assert_init support
> - move debug_kwork_activate/debug_kwork_deactivate before list operation
> - name the kconfig CONFIG_DEBUG_OBJECTS_KTHREAD_WORK
> - use kthread_init_work_onstack/destroy_kwork_on_stack when kthread_work used
> on stack
> - __init_kwork before clear kthread_work in kthread_init_work
> ---
> include/linux/kthread.h | 30 +-
> include/linux/poison.h | 4 ++
> kernel/kthread.c| 142
> +---
> lib/Kconfig.debug | 10
> 4 files changed, 176 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/kthread.h b/include/linux/kthread.h
> index 65b81e0..706302b 100644
> --- a/include/linux/kthread.h
> +++ b/include/linux/kthread.h
> @@ -108,6 +108,17 @@ struct kthread_delayed_work {
> struct timer_list timer;
> };
>
> +#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD_WORK
> +extern void __init_kwork(struct kthread_work *kwork, int onstack);
> +extern void destroy_kwork_on_stack(struct kthread_work *kwork);
> +extern void destroy_delayed_kwork_on_stack(struct kthread_delayed_work
> *kdwork);
> +#else
> +static inline void __init_kwork(struct kthread_work *kwork, int onstack) { }
> +static inline void destroy_kwork_on_stack(struct kthread_work *kwork) { }
> +static inline void destroy_delayed_kwork_on_stack(struct
> kthread_delayed_work *kdwork) { }
> +#endif
> +
> +
> #define KTHREAD_WORKER_INIT(worker){ \
> .lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock),\
> .work_list = LIST_HEAD_INIT((worker).work_list),\
> @@ -115,7 +126,7 @@ struct kthread_delayed_work {
> }
>
> #define KTHREAD_WORK_INIT(work, fn){ \
> - .node = LIST_HEAD_INIT((work).node),\
> + .node = { .next = KWORK_ENTRY_STATIC }, \
> .func = (fn), \
> }
>
> @@ -159,6 +170,15 @@ extern void __kthread_init_worker(struct kthread_worker
> *worker,
>
> #define kthread_init_work(work, fn)\
> do {\
> + __init_kwork(work, 0);
> \
> + memset((work), 0, sizeof(struct kthread_work)); \
> + INIT_LIST_HEAD(&(work)->node); \
> + (work)->func = (fn);\
> + } while (0)
> +
> +#define kthread_init_work_onstack(work, fn)
> \
> + do {\
> + __init_kwork(work, 1);
> \
> memset((work), 0, sizeof(struct kthread_work)); \
> INIT_LIST_HEAD(&(work)->node); \
> (work)->func = (fn);\
> @@ -172,6 +192,14 @@ extern void __kthread_init_worker(struct kthread_worker
> *worker,
> TIMER_IRQSAFE);\
> } while (0)
>
> +#define kthread_init_delayed_work_onstack(dwork, fn)
> \
> + do {\
> + kthread_init_work_onstack(&(dwork)->work, (fn));
> \
> + __init_timer_on_stack(&(dwork)->timer,
> \
> +kthread_delayed_work_timer_fn, \
> +TIMER_IRQSAFE);\
> + } while (0)
> +
> int kthread_worker_fn(void *worker_ptr);
>
> __printf(2, 3)
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index
Re: [PATCH] Input: i8042 - Add ByteSpeed touchpad to noloop table
On Tue, Dec 01, 2020 at 01:47:23PM +0800, Po-Hsu Lin wrote: > It looks like the C15B laptop got another vendor: ByteSpeed LLC. > > Avoid AUX loopback on this touchpad as well, thus input subsystem will > be able to recognize a Synaptics touchpad in the AUX port. > > BugLink: https://bugs.launchpad.net/bugs/1906128 > Signed-off-by: Po-Hsu Lin Applied, thank you. -- Dmitry
Re: [PATCH] INPUT: xpad: support Ardwiino Controllers
Hi Sanjay,
On Thu, Nov 26, 2020 at 10:25:40PM +1300, Sanjay Govind wrote:
> This commit adds support for Ardwiino Controllers
Unfortunately the patch is line-wrapped, with tabs removed, and
therefore can not be applied. It is also sent as HTML so most mailing
lists dropped it. I guess you sent it through gmail's web interface,
which is known not to work for patch submission. Could you please resend
via "git send-email" which will ensure that it is formatted properly.
>
> Signed-off-by: Sanjay Govind
> ---
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index c77cdb3b62b5..c9d78e2acb38 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -418,6 +418,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOXONE_VENDOR(0x0f0d),/* Hori Controllers */
> XPAD_XBOX360_VENDOR(0x1038),/* SteelSeries Controllers
> */
> XPAD_XBOX360_VENDOR(0x11c9),/* Nacon GC100XF */
> + XPAD_XBOX360_VENDOR(0x1209),/* Ardwiino Controllers */
> XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
> XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360
> controllers */
> XPAD_XBOX360_VENDOR(0x146b),/* BigBen Interactive
> Controllers */
Thanks.
--
Dmitry
Re: [PATCH] s390: cio: fix two use-after-free bugs in device.c
在 2020/11/20 15:55, Cornelia Huck 写道:
On Fri, 20 Nov 2020 15:48:49 +0800
Qinglang Miao wrote:
put_device calls release function which do kfree() inside.
So following use of sch would cause use-after-free bugs.
Fix these by simply adjusting the position of put_device.
Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
Fixes: 74bd0d859dc3 ("s390/cio: fix unlocked access of online member")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/s390/cio/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index b29fe8d50..69492417b 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1664,10 +1664,10 @@ void __init ccw_device_destroy_console(struct
ccw_device *cdev)
struct io_subchannel_private *io_priv = to_io_private(sch);
set_io_private(sch, NULL);
- put_device(>dev);
- put_device(>dev);
dma_free_coherent(>dev, sizeof(*io_priv->dma_area),
io_priv->dma_area, io_priv->dma_area_dma);
+ put_device(>dev);
+ put_device(>dev);
That change looks reasonable.
kfree(io_priv);
}
@@ -1774,8 +1774,8 @@ static int ccw_device_remove(struct device *dev)
ret, cdev->private->dev_id.ssid,
cdev->private->dev_id.devno);
/* Give up reference obtained in ccw_device_set_online(). */
- put_device(>dev);
spin_lock_irq(cdev->ccwlock);
+ put_device(>dev);
As the comment above states, the put_device() gives up the reference
obtained in ccw_device_set_online(). There's at least one more
reference remaining (held by the caller of the remove function). Moving
the put_device() does not fix anything here.
Hi, Cornelia
Sorry for the delayed reply.
Your suggestion is reasonable, there is a mistake in this patch for I
didn't notice that there would be at least one more reference remaining.
So I sent a new patch only to move put_device after dma_free_coherent. I
put the link as below:
https://lore.kernel.org/lkml/20201201063150.82128-1-miaoqingl...@huawei.com/
Thanks!
}
ccw_device_set_timeout(cdev, 0);
cdev->drv = NULL;
.
Re: [PATCH] input: raydium_ts_i2c: Do not split tx transactions
Hi Furquan, On Mon, Nov 30, 2020 at 10:00:50PM -0800, Furquan Shaikh wrote: > Raydium device does not like splitting of tx transactions into > multiple messages - one for the register address and one for the > actual data. This results in incorrect behavior on the device side. > > This change updates raydium_i2c_read and raydium_i2c_write to create > i2c_msg arrays separately and passes those arrays into > raydium_i2c_xfer which decides based on the address whether the bank > switch command should be sent. The bank switch header is still added > by raydium_i2c_read and raydium_i2c_write to ensure that all these > operations are performed as part of a single I2C transfer. It > guarantees that no other transactions are initiated to any other > device on the same bus after the bank switch command is sent. i2c_transfer locks the bus [segment] for the entire time, so this explanation on why the change is needed does not make sense. Also, does it help if you mark the data message as I2C_M_NOSTART in case of writes? I also wonder if we should convert the driver to regmap, which should help with handling the bank switch as well as figuring out if it can do "gather write" or fall back to allocating an additional send buffer. Thanks. -- Dmitry
Re: [PATCH v2 4/4] soc: qcom: llcc-qcom: Add support for SM8250 SoC
On 2020-11-30 15:09, Manivannan Sadhasivam wrote:
SM8250 SoC uses LLCC IP version 2. In this version, the WRSC_EN
register
needs to be written to enable the Write Sub Cache for each SCID. Hence,
use a dedicated "write_scid_en" member with predefined values and write
them for LLCC IP version 2.
Signed-off-by: Manivannan Sadhasivam
---
Reviewed-by: Sai Prakash Ranjan
drivers/soc/qcom/llcc-qcom.c | 38 ++
include/linux/soc/qcom/llcc-qcom.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/drivers/soc/qcom/llcc-qcom.c
b/drivers/soc/qcom/llcc-qcom.c
index a559617ea7c0..8403a77b59fe 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -51,6 +51,7 @@
#define LLCC_TRP_SCID_DIS_CAP_ALLOC 0x21f00
#define LLCC_TRP_PCB_ACT 0x21f04
+#define LLCC_TRP_WRSC_EN 0x21f20
#define BANK_OFFSET_STRIDE 0x8
@@ -77,6 +78,7 @@
* then the ways assigned to this client are not flushed
on power
* collapse.
* @activate_on_init: Activate the slice immediately after it is
programmed
+ * @write_scid_en: Bit enables write cache support for a given scid.
*/
struct llcc_slice_config {
u32 usecase_id;
@@ -91,6 +93,7 @@ struct llcc_slice_config {
bool dis_cap_alloc;
bool retain_on_pc;
bool activate_on_init;
+ bool write_scid_en;
};
struct qcom_llcc_config {
@@ -151,6 +154,25 @@ static const struct llcc_slice_config
sm8150_data[] = {
{ LLCC_WRCACHE, 31, 128, 1, 1, 0xFFF, 0x0, 0, 0, 0, 0, 0 },
};
+static const struct llcc_slice_config sm8250_data[] = {
+ { LLCC_CPUSS,1, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 1, 0 },
+ { LLCC_VIDSC0, 2, 512, 3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_AUDIO,6, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 0, 0, 0 },
+ { LLCC_CMPT,10, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 0, 0, 0 },
+ { LLCC_GPUHTW, 11, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_GPU, 12, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 1 },
+ { LLCC_MMUHWT, 13, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
+ { LLCC_CMPTDMA, 15, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_DISP,16, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_VIDFW, 17, 512, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_AUDHW, 22, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_NPU, 23, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_WLHW,24, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_CVP, 28, 256, 3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_APTCM, 30, 128, 3, 0, 0x0, 0x3, 1, 0, 0, 1, 0, 0 },
+ { LLCC_WRCACHE, 31, 256, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
+};
+
static const struct qcom_llcc_config sc7180_cfg = {
.sct_data = sc7180_data,
.size = ARRAY_SIZE(sc7180_data),
@@ -168,6 +190,11 @@ static const struct qcom_llcc_config sm8150_cfg =
{
.size = ARRAY_SIZE(sm8150_data),
};
+static const struct qcom_llcc_config sm8250_cfg = {
+ .sct_data = sm8250_data,
+ .size = ARRAY_SIZE(sm8250_data),
+};
+
static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
/**
@@ -417,6 +444,16 @@ static int _qcom_llcc_cfg_program(const struct
llcc_slice_config *config,
return ret;
}
+ if (drv_data->major_version == 2) {
+ u32 wren;
+
+ wren = config->write_scid_en << config->slice_id;
+ ret = regmap_update_bits(drv_data->bcast_regmap,
LLCC_TRP_WRSC_EN,
+BIT(config->slice_id), wren);
+ if (ret)
+ return ret;
+ }
+
if (config->activate_on_init) {
desc.slice_id = config->slice_id;
ret = llcc_slice_activate();
@@ -571,6 +608,7 @@ static const struct of_device_id
qcom_llcc_of_match[] = {
{ .compatible = "qcom,sc7180-llcc", .data = _cfg },
{ .compatible = "qcom,sdm845-llcc", .data = _cfg },
{ .compatible = "qcom,sm8150-llcc", .data = _cfg },
+ { .compatible = "qcom,sm8250-llcc", .data = _cfg },
{ }
};
diff --git a/include/linux/soc/qcom/llcc-qcom.h
b/include/linux/soc/qcom/llcc-qcom.h
index d17a3de80510..64fc582ae415 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -29,6 +29,7 @@
#define LLCC_AUDHW 22
#define LLCC_NPU 23
#define LLCC_WLHW24
+#define LLCC_CVP 28
#define LLCC_MODPE 29
#define LLCC_APTCM 30
#define LLCC_WRCACHE 31
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] s390: cio: fix use-after-free in ccw_device_destroy_console
put_device calls release function which do kfree() inside.
So following use of sch would cause use-after-free bugs.
Fix these by simply adjusting the position of put_device.
Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support")
Reported-by: Hulk Robot
Suggested-by: Cornelia Huck
Signed-off-by: Qinglang Miao
---
This patch is indeed a v2 of older one. Considering that the
patch's name has changed, I think a normal prefix 'PATCH' is
better.
drivers/s390/cio/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index b29fe8d50..33280ca18 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1664,10 +1664,10 @@ void __init ccw_device_destroy_console(struct
ccw_device *cdev)
struct io_subchannel_private *io_priv = to_io_private(sch);
set_io_private(sch, NULL);
- put_device(>dev);
- put_device(>dev);
dma_free_coherent(>dev, sizeof(*io_priv->dma_area),
io_priv->dma_area, io_priv->dma_area_dma);
+ put_device(>dev);
+ put_device(>dev);
kfree(io_priv);
}
--
2.23.0
[PATCH] arm64: dts: meson: add i2c3/rtc nodes and vrtc alias to GT-King/GT-King-Pro
The GT-King and GT-King-Pro boxes have an RTC chip and power cell, so enable it.
GTKING:~ # dmesg | grep rtc
[5.237245] meson-vrtc ff8000a8.rtc: registered as rtc1
[5.261869] rtc-hym8563 0-0051: registered as rtc0
[5.265016] rtc-hym8563 0-0051: setting system clock to 2020-11-30T09:16:54
UTC (1606727814)
Signed-off-by: Christian Hewitt
---
.../boot/dts/amlogic/meson-g12b-gtking-pro.dts | 17 +
.../boot/dts/amlogic/meson-g12b-gtking.dts | 18 ++
2 files changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
index f0c56a16af3d..0e5c500fb78f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
@@ -14,6 +14,11 @@
compatible = "azw,gtking", "amlogic,g12b";
model = "Beelink GT-King Pro";
+ aliases {
+ rtc0 =
+ rtc1 =
+ };
+
gpio-keys-polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
@@ -112,6 +117,18 @@
status = "okay";
};
+ {
+ status = "okay";
+ pinctrl-0 = <_sda_a_pins>, <_sck_a_pins>;
+ pinctrl-names = "default";
+
+ rtc: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ wakeup-source;
+ };
+};
+
_b {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
index eeb7bc5539ef..10b87eb97b14 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
@@ -14,6 +14,11 @@
compatible = "azw,gtking", "amlogic,g12b";
model = "Beelink GT-King";
+ aliases {
+ rtc0 =
+ rtc1 =
+ };
+
spdif_dit: audio-codec-1 {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dit";
@@ -122,6 +127,19 @@
status = "okay";
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_sda_a_pins>, <_sck_a_pins>;
+ pinctrl-names = "default";
+
+ rtc: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ wakeup-source;
+ };
+};
+
{
pinctrl-0 = <_out_h_pins>;
pinctrl-names = "default";
--
2.17.1
[PATCH v5 5/7] rtc: New driver for RTC in Netronix embedded controller
With this driver, mainline Linux can keep its time and date in sync with
the vendor kernel.
Advanced functionality like alarm and automatic power-on is not yet
supported.
Signed-off-by: Jonathan Neuschäfer
Acked-by: Alexandre Belloni
---
v5:
- Add Alexandre Belloni's A-b
- Use regmap_multi_reg_write
v4:
- https://lore.kernel.org/lkml/2020112739.1455132-6-j.neuschae...@gmx.net/
- Remove "driver" from Kconfig entry for consistency with most other entries
- Add missing MODULE_ALIAS line
- Give NTXEC_REG_READ_ macros longer names
- Solve the read tearing issue using Alexandre Belloni's algorithm
- Solve the write tearing issue using Uwe Kleine-König's algorithm
- Spell out ODM
v3:
- https://lore.kernel.org/lkml/20200924192455.2484005-6-j.neuschae...@gmx.net/
- Add email address to copyright line
- Remove OF compatible string and don't include linux/of_device.h
- Don't use a comma after sentinels
- Avoid ret |= ... pattern
- Move 8-bit register conversion to ntxec.h
- Relicense as GPLv2 or later
v2:
- https://lore.kernel.org/lkml/20200905133230.1014581-7-j.neuschae...@gmx.net/
- Rework top-of-file comment [Lee Jones]
- Sort the #include lines [Alexandre Belloni]
- don't align = signs in struct initializers [Uwe Kleine-König]
- Switch to regmap
- Fix register number used to read minutes and seconds
- Prefix registers with NTXEC_REG_
- Add help text to the Kconfig option
- Use devm_rtc_allocate_device and rtc_register_device, set ->range_min and
->range_max
---
drivers/rtc/Kconfig | 8 +++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-ntxec.c | 143
3 files changed, 152 insertions(+)
create mode 100644 drivers/rtc/rtc-ntxec.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 65ad9d0b47ab1..fe009949728b3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1311,6 +1311,14 @@ config RTC_DRV_CROS_EC
This driver can also be built as a module. If so, the module
will be called rtc-cros-ec.
+config RTC_DRV_NTXEC
+ tristate "Netronix embedded controller RTC"
+ depends on MFD_NTXEC
+ help
+ Say yes here if you want to support the RTC functionality of the
+ embedded controller found in certain e-book readers designed by the
+ original design manufacturer Netronix.
+
comment "on-CPU RTC drivers"
config RTC_DRV_ASM9260
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index bfb57464118d0..5f2a7582b2780 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_RTC_DRV_MT7622)+= rtc-mt7622.o
obj-$(CONFIG_RTC_DRV_MV) += rtc-mv.o
obj-$(CONFIG_RTC_DRV_MXC) += rtc-mxc.o
obj-$(CONFIG_RTC_DRV_MXC_V2) += rtc-mxc_v2.o
+obj-$(CONFIG_RTC_DRV_NTXEC)+= rtc-ntxec.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_PALMAS) += rtc-palmas.o
diff --git a/drivers/rtc/rtc-ntxec.c b/drivers/rtc/rtc-ntxec.c
new file mode 100644
index 0..c7cff7802895b
--- /dev/null
+++ b/drivers/rtc/rtc-ntxec.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * The Netronix embedded controller is a microcontroller found in some
+ * e-book readers designed by the original design manufacturer Netronix, Inc.
+ * It contains RTC, battery monitoring, system power management, and PWM
+ * functionality.
+ *
+ * This driver implements access to the RTC time and date.
+ *
+ * Copyright 2020 Jonathan Neuschäfer
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ntxec_rtc {
+ struct device *dev;
+ struct ntxec *ec;
+};
+
+#define NTXEC_REG_WRITE_YEAR 0x10
+#define NTXEC_REG_WRITE_MONTH 0x11
+#define NTXEC_REG_WRITE_DAY0x12
+#define NTXEC_REG_WRITE_HOUR 0x13
+#define NTXEC_REG_WRITE_MINUTE 0x14
+#define NTXEC_REG_WRITE_SECOND 0x15
+
+#define NTXEC_REG_READ_YEAR_MONTH 0x20
+#define NTXEC_REG_READ_MDAY_HOUR 0x21
+#define NTXEC_REG_READ_MINUTE_SECOND 0x23
+
+static int ntxec_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct ntxec_rtc *rtc = dev_get_drvdata(dev);
+ unsigned int value;
+ int res;
+
+retry:
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MINUTE_SECOND,
);
+ if (res < 0)
+ return res;
+
+ tm->tm_min = value >> 8;
+ tm->tm_sec = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_MDAY_HOUR, );
+ if (res < 0)
+ return res;
+
+ tm->tm_mday = value >> 8;
+ tm->tm_hour = value & 0xff;
+
+ res = regmap_read(rtc->ec->regmap, NTXEC_REG_READ_YEAR_MONTH, );
+ if (res < 0)
+ return res;
+
+ tm->tm_year = (value >> 8) + 100;
+ tm->tm_mon = (value & 0xff) - 1;
+
+ /*
+* Read the minutes/seconds field again. If it changed since the first
+* read, we can't assume that the values read so far are consistent,
+
Re: [PATCH] scsi: storvsc: Fix error return in storvsc_probe()
On Fri, 27 Nov 2020 11:02:06 +0800, Jing Xiangfeng wrote: > Fix to return a error code "-ENOMEM" from the error handling case > instead of 0. Applied to 5.10/scsi-fixes, thanks! [1/1] scsi: storvsc: Fix error return in storvsc_probe() https://git.kernel.org/mkp/scsi/c/6112ff4e8f39 -- Martin K. Petersen Oracle Linux Engineering
linux-next: build failure after merge of the phy-next tree
Hi all,
After merging the phy-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/phy/ralink/phy-mt7621-pci.c:17:10: fatal error: mt7621.h: No such file
or directory
17 | #include
| ^~
Caused by commit
d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpGKECLV4LT1.pgp
Description: OpenPGP digital signature
Re: [PATCH] scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback()
On Wed, 18 Nov 2020 15:53:48 +0100, Andrea Parri (Microsoft) wrote: > Check that the packet is of the expected size at least, don't copy > data past the packet. Applied to 5.10/scsi-fixes, thanks! [1/1] scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback() https://git.kernel.org/mkp/scsi/c/3b8c72d076c4 -- Martin K. Petersen Oracle Linux Engineering
Re: [RFC PATCH 3/3] KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort()
Hi Will,
On 2020/11/30 21:49, Will Deacon wrote:
On Mon, Nov 30, 2020 at 08:18:47PM +0800, Yanan Wang wrote:
If we get a FSC_PERM fault, just using (logging_active && writable) to determine
calling kvm_pgtable_stage2_map(). There will be two more cases we should
consider.
(1) After logging_active is configged back to false from true. When we get a
FSC_PERM fault with write_fault and adjustment of hugepage is needed, we should
merge tables back to a block entry. This case is ignored by still calling
kvm_pgtable_stage2_relax_perms(), which will lead to an endless loop and guest
panic due to soft lockup.
(2) We use (FSC_PERM && logging_active && writable) to determine collapsing
a block entry into a table by calling kvm_pgtable_stage2_map(). But sometimes
we may only need to relax permissions when trying to write to a page other than
a block. In this condition, using kvm_pgtable_stage2_relax_perms() will be fine.
The ISS filed bit[1:0] in ESR_EL2 regesiter indicates the stage2 lookup level
at which a D-abort or I-abort occured. By comparing granule of the fault lookup
level with vma_pagesize, we can strictly distinguish conditions of calling
kvm_pgtable_stage2_relax_perms() or kvm_pgtable_stage2_map(), and the above
two cases will be well considered.
Suggested-by: Keqian Zhu
Signed-off-by: Yanan Wang
---
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/kvm_emulate.h | 5 +
arch/arm64/kvm/mmu.c | 11 +--
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 22c81f1edda2..85a3e49f92f4 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -104,6 +104,7 @@
/* Shared ISS fault status code(IFSC/DFSC) for Data/Instruction aborts */
#define ESR_ELx_FSC (0x3F)
#define ESR_ELx_FSC_TYPE (0x3C)
+#define ESR_ELx_FSC_LEVEL (0x03)
#define ESR_ELx_FSC_EXTABT(0x10)
#define ESR_ELx_FSC_SERROR(0x11)
#define ESR_ELx_FSC_ACCESS(0x08)
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index 5ef2669ccd6c..2e0e8edf6306 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -350,6 +350,11 @@ static __always_inline u8
kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vc
return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC_TYPE;
}
+static __always_inline u8 kvm_vcpu_trap_get_fault_level(const struct kvm_vcpu *vcpu)
+{
+ return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC_LEVEL;
+{
+
static __always_inline bool kvm_vcpu_abt_issea(const struct kvm_vcpu *vcpu)
{
switch (kvm_vcpu_trap_get_fault(vcpu)) {
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 1a01da9fdc99..75814a02d189 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -754,10 +754,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
gfn_t gfn;
kvm_pfn_t pfn;
bool logging_active = memslot_is_logging(memslot);
- unsigned long vma_pagesize;
+ unsigned long fault_level = kvm_vcpu_trap_get_fault_level(vcpu);
+ unsigned long vma_pagesize, fault_granule;
enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
struct kvm_pgtable *pgt;
+ fault_granule = 1UL << ARM64_HW_PGTABLE_LEVEL_SHIFT(fault_level);
I like the idea, but is this macro reliable for stage-2 page-tables, given
that we could have a concatenated pgd?
Will
.
Yes, it's fine even when we have a concatenated pgd table.
No matter a concatenated pgd will be made or not, the initial lookup
level (start _level) is set in VTCR_EL2 register.
The MMU hardware walker will know the start_level according to
information in VTCR_EL2.
This idea runs well in practice on host where ia_bits is 40, PAGE_SIZE
is 4k, and a concatenated pgd is made for guest stage2.
According to the kernel info printed, the start_level is 1, and stage 2
translation runs as expected.
Yanan
[PATCH] input: raydium_ts_i2c: Do not split tx transactions
Raydium device does not like splitting of tx transactions into
multiple messages - one for the register address and one for the
actual data. This results in incorrect behavior on the device side.
This change updates raydium_i2c_read and raydium_i2c_write to create
i2c_msg arrays separately and passes those arrays into
raydium_i2c_xfer which decides based on the address whether the bank
switch command should be sent. The bank switch header is still added
by raydium_i2c_read and raydium_i2c_write to ensure that all these
operations are performed as part of a single I2C transfer. It
guarantees that no other transactions are initiated to any other
device on the same bus after the bank switch command is sent.
Signed-off-by: Furquan Shaikh
---
drivers/input/touchscreen/raydium_i2c_ts.c | 120 ++---
1 file changed, 82 insertions(+), 38 deletions(-)
diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c
b/drivers/input/touchscreen/raydium_i2c_ts.c
index e694a9b2b1e5..259ecfdf33f1 100644
--- a/drivers/input/touchscreen/raydium_i2c_ts.c
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -137,45 +137,25 @@ struct raydium_data {
bool wake_irq_enabled;
};
-static int raydium_i2c_xfer(struct i2c_client *client,
- u32 addr, void *data, size_t len, bool is_read)
-{
- struct raydium_bank_switch_header {
- u8 cmd;
- __be32 be_addr;
- } __packed header = {
- .cmd = RM_CMD_BANK_SWITCH,
- .be_addr = cpu_to_be32(addr),
- };
-
- u8 reg_addr = addr & 0xff;
-
- struct i2c_msg xfer[] = {
- {
- .addr = client->addr,
- .len = sizeof(header),
- .buf = (u8 *),
- },
- {
- .addr = client->addr,
- .len = 1,
- .buf = _addr,
- },
- {
- .addr = client->addr,
- .len = len,
- .buf = data,
- .flags = is_read ? I2C_M_RD : 0,
- }
- };
+/*
+ * Header to be sent for RM_CMD_BANK_SWITCH command. This is used by
+ * raydium_i2c_{read|send} below.
+ */
+struct __packed raydium_bank_switch_header {
+ u8 cmd;
+ __be32 be_addr;
+};
+static int raydium_i2c_xfer(struct i2c_client *client, u32 addr,
+ struct i2c_msg *xfer, size_t xfer_count)
+{
+ int ret;
/*
* If address is greater than 255, then RM_CMD_BANK_SWITCH needs to be
* sent first. Else, skip the header i.e. xfer[0].
*/
int xfer_start_idx = (addr > 0xff) ? 0 : 1;
- size_t xfer_count = ARRAY_SIZE(xfer) - xfer_start_idx;
- int ret;
+ xfer_count -= xfer_start_idx;
ret = i2c_transfer(client->adapter, [xfer_start_idx], xfer_count);
if (likely(ret == xfer_count))
@@ -189,10 +169,43 @@ static int raydium_i2c_send(struct i2c_client *client,
{
int tries = 0;
int error;
+ u8 *tx_buf;
+ u8 reg_addr = addr & 0xff;
+
+ tx_buf = kmalloc(len + 1, GFP_KERNEL);
+ if (!tx_buf)
+ return -ENOMEM;
+
+ tx_buf[0] = reg_addr;
+ memcpy(tx_buf + 1, data, len);
do {
- error = raydium_i2c_xfer(client, addr, (void *)data, len,
-false);
+ struct raydium_bank_switch_header header = {
+ .cmd = RM_CMD_BANK_SWITCH,
+ .be_addr = cpu_to_be32(addr),
+ };
+
+ /*
+* Perform as a single i2c_transfer transaction to ensure that
+* no other I2C transactions are initiated on the bus to any
+* other device in between. Initiating transacations to other
+* devices after RM_CMD_BANK_SWITCH is sent is known to cause
+* issues.
+*/
+ struct i2c_msg xfer[] = {
+ {
+ .addr = client->addr,
+ .len = sizeof(header),
+ .buf = (u8 *),
+ },
+ {
+ .addr = client->addr,
+ .len = len + 1,
+ .buf = tx_buf,
+ },
+ };
+
+ error = raydium_i2c_xfer(client, addr, xfer, ARRAY_SIZE(xfer));
if (likely(!error))
return 0;
@@ -206,12 +219,43 @@ static int raydium_i2c_send(struct i2c_client *client,
static int raydium_i2c_read(struct i2c_client *client,
u32 addr, void *data, size_t len)
{
- size_t xfer_len;
int error;
while (len) {
- xfer_len = min_t(size_t, len, RM_MAX_READ_SIZE);
[PATCH v5] drm/bridge: add it6505 driver
This adds support for the iTE IT6505. This device can convert DPI signal to DP output. From: Allen Chen Signed-off-by: Jitao Shi Signed-off-by: Pi-Hsun Shih Signed-off-by: Yilun Lin Signed-off-by: Hermes Wu Signed-off-by: Allen Chen --- drivers/gpu/drm/bridge/Kconfig |7 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++ 3 files changed, 3351 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3c..25d34d7196004 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT6505 + tristate "ITE IT6505 DisplayPort bridge" + depends on OF + select DRM_KMS_HELPER + help + ITE IT6505 DisplayPort bridge chip driver. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d6..2b2f8f0b5b0fa 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += megachips-stdp-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c new file mode 100644 index 0..e4251c69fc991 --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it6505.c @@ -0,0 +1,3343 @@ +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define REG_IC_VER 0x04 + +#define REG_RESET_CTRL 0x05 +#define VIDEO_RESET BIT(0) +#define AUDIO_RESET BIT(1) +#define ALL_LOGIC_RESET BIT(2) +#define AUX_RESET BIT(3) +#define HDCP_RESET BIT(4) + +#define INT_STATUS_01 0x06 +#define INT_MASK_01 0x09 +#define INT_HPD_CHANGE BIT(0) +#define INT_RECEIVE_HPD_IRQ BIT(1) +#define INT_SCDT_CHANGE BIT(2) +#define INT_HDCP_FAIL BIT(3) +#define INT_HDCP_DONE BIT(4) + +#define INT_STATUS_02 0x07 +#define INT_MASK_02 0x0A +#define INT_AUX_CMD_FAIL BIT(0) +#define INT_HDCP_KSV_CHECK BIT(1) +#define INT_AUDIO_FIFO_ERROR BIT(2) + +#define INT_STATUS_03 0x08 +#define INT_MASK_03 0x0B +#define INT_LINK_TRAIN_FAIL BIT(4) +#define INT_VID_FIFO_ERROR BIT(5) +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7) + +#define REG_SYSTEM_STS 0x0D +#define INT_STS BIT(0) +#define HPD_STS BIT(1) +#define VIDEO_STB BIT(2) + +#define REG_LINK_TRAIN_STS 0x0E +#define LINK_STATE_CR BIT(2) +#define LINK_STATE_EQ BIT(3) +#define LINK_STATE_NORP BIT(4) + +#define REG_BANK_SEL 0x0F +#define REG_CLK_CTRL0 0x10 +#define M_PCLK_DELAY 0x03 + +#define REG_AUX_OPT 0x11 +#define AUX_AUTO_RST BIT(0) +#define AUX_FIX_FREQ BIT(3) + +#define REG_DATA_CTRL0 0x12 +#define VIDEO_LATCH_EDGE BIT(4) +#define ENABLE_PCLK_COUNTER BIT(7) + +#define REG_PCLK_COUNTER_VALUE 0x13 + +#define REG_501_FIFO_CTRL 0x15 +#define RST_501_FIFO BIT(1) + +#define REG_TRAIN_CTRL0 0x16 +#define FORCE_LBR BIT(0) +#define LANE_COUNT_MASK 0x06 +#define LANE_SWAP BIT(3) +#define SPREAD_AMP_5 BIT(4) +#define FORCE_CR_DONE BIT(5) +#define FORCE_EQ_DONE BIT(6) + +#define REG_TRAIN_CTRL1 0x17 +#define AUTO_TRAIN BIT(0) +#define MANUAL_TRAIN BIT(1) +#define FORCE_RETRAIN BIT(2) + +#define REG_AUX_CTRL 0x23 +#define CLR_EDID_FIFO BIT(0) +#define AUX_USER_MODE BIT(1) +#define AUX_NO_SEGMENT_WR BIT(6) +#define AUX_EN_FIFO_READ BIT(7) + +#define REG_AUX_ADR_0_7 0x24 +#define REG_AUX_ADR_8_15 0x25 +#define REG_AUX_ADR_16_19 0x26 +#define REG_AUX_OUT_DATA0 0x27 + +#define REG_AUX_CMD_REQ 0x2B +#define AUX_BUSY BIT(5) + +#define REG_AUX_DATA_0_7 0x2C +#define REG_AUX_DATA_8_15 0x2D +#define REG_AUX_DATA_16_23 0x2E +#define REG_AUX_DATA_24_31 0x2F + +#define REG_AUX_DATA_FIFO 0x2F + +#define REG_AUX_ERROR_STS 0x9F +#define M_AUX_REQ_FAIL 0x03 + +#define REG_HDCP_CTRL1 0x38 +#define HDCP_CP_ENABLE BIT(0) + +#define REG_HDCP_TRIGGER 0x39 +#define HDCP_TRIGGER_START BIT(0) +#define HDCP_TRIGGER_CPIRQ BIT(1) +#define HDCP_TRIGGER_KSV_DONE BIT(4) +#define HDCP_TRIGGER_KSV_FAIL BIT(5) + +#define REG_HDCP_CTRL2 0x3A +#define HDCP_AN_SEL BIT(0)
Re: [PATCH 000/141] Fix fall-through warnings for Clang
Gustavo, > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. -- Martin K. Petersen Oracle Linux Engineering
[PATCH] Input: i8042 - Add ByteSpeed touchpad to noloop table
It looks like the C15B laptop got another vendor: ByteSpeed LLC.
Avoid AUX loopback on this touchpad as well, thus input subsystem will
be able to recognize a Synaptics touchpad in the AUX port.
BugLink: https://bugs.launchpad.net/bugs/1906128
Signed-off-by: Po-Hsu Lin
---
drivers/input/serio/i8042-x86ia64io.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index a4c9b96..7ecb651 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -219,6 +219,10 @@ static const struct dmi_system_id __initconst
i8042_dmi_noloop_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
},
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ByteSpeed LLC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ByteSpeed Laptop C15B"),
+ },
},
{ }
};
--
2.7.4
