* [PATCH v9 2/8] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-12-10 12:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides arm64.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
include/linux/uaccess.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1cdd47..42b7a4ac65e2 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -13,6 +13,10 @@
#include <asm/uaccess.h>
+#ifndef untagged_addr
+#define untagged_addr(addr) (addr)
+#endif
+
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
* and get rid of their private instances of copy_{to,from}_user() and
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 4/8] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Since a user can provided tagged addresses, we need
to handle such case.
Add untagging to gup.c functions that use user addresses for vma lookup.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/gup.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index 8cb68a50dbdf..409aedb1e2d5 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -683,6 +683,8 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (!nr_pages)
return 0;
+ start = untagged_addr(start);
+
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
/*
@@ -845,6 +847,8 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
struct vm_area_struct *vma;
vm_fault_t ret, major = 0;
+ address = untagged_addr(address);
+
if (unlocked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 8/8] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile | 11 +++++++++++
.../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++++++
tools/testing/selftests/arm64/tags_test.c | 19 +++++++++++++++++++
4 files changed, 43 insertions(+)
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
new file mode 100644
index 000000000000..e8fae8d61ed6
--- /dev/null
+++ b/tools/testing/selftests/arm64/.gitignore
@@ -0,0 +1 @@
+tags_test
diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
new file mode 100644
index 000000000000..a61b2e743e99
--- /dev/null
+++ b/tools/testing/selftests/arm64/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+
+# ARCH can be overridden by the user for cross compiling
+ARCH ?= $(shell uname -m 2>/dev/null || echo not)
+
+ifneq (,$(filter $(ARCH),aarch64 arm64))
+TEST_GEN_PROGS := tags_test
+TEST_PROGS := run_tags_test.sh
+endif
+
+include ../lib.mk
diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
new file mode 100755
index 000000000000..745f11379930
--- /dev/null
+++ b/tools/testing/selftests/arm64/run_tags_test.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+echo "--------------------"
+echo "running tags test"
+echo "--------------------"
+./tags_test
+if [ $? -ne 0 ]; then
+ echo "[FAIL]"
+else
+ echo "[PASS]"
+fi
diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
new file mode 100644
index 000000000000..1452ed7d33f9
--- /dev/null
+++ b/tools/testing/selftests/arm64/tags_test.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <sys/utsname.h>
+
+#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
+#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
+ SHIFT_TAG(tag))
+
+int main(void)
+{
+ struct utsname utsname;
+ void *ptr = &utsname;
+ void *tagged_ptr = (void *)SET_TAG(ptr, 0x42);
+ int err = uname(tagged_ptr);
+ return err;
+}
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 7/8] arm64: update Documentation/arm64/tagged-pointers.txt
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
Document the changes in Documentation/arm64/tagged-pointers.txt.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
Documentation/arm64/tagged-pointers.txt | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index a25a99e82bb1..f4cf1f5cf362 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -17,13 +17,22 @@ this byte for application use.
Passing tagged addresses to the kernel
--------------------------------------
-All interpretation of userspace memory addresses by the kernel assumes
-an address tag of 0x00.
+The kernel supports tags in pointer arguments (including pointers in
+structures) for a limited set of syscalls, the exceptions are:
-This includes, but is not limited to, addresses found in:
+ - memory syscalls: brk, madvise, mbind, mincore, mlock, mlock2, move_pages,
+ mprotect, mremap, msync, munlock, munmap, pkey_mprotect, process_vm_readv,
+ process_vm_writev, remap_file_pages;
- - pointer arguments to system calls, including pointers in structures
- passed to system calls,
+ - ioctls that accept user pointers that describe virtual memory ranges;
+
+ - TCP_ZEROCOPY_RECEIVE setsockopt.
+
+The kernel supports tags in user fault addresses. However the fault_address
+field in the sigcontext struct will contain an untagged address.
+
+All other interpretations of userspace memory addresses by the kernel
+assume an address tag of 0x00, in particular:
- the stack pointer (sp), e.g. when interpreting it to deliver a
signal,
@@ -33,11 +42,7 @@ This includes, but is not limited to, addresses found in:
Using non-zero address tags in any of these locations may result in an
error code being returned, a (fatal) signal being raised, or other modes
-of failure.
-
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
-strongly discouraged.
+of failure. Using a non-zero address tag for sp is strongly discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
address tags may suffer impaired or inaccurate debug and profiling
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 5/8] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index b53e1b5d80f4..97467cd2bc59 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -106,6 +106,8 @@ long strncpy_from_user(char *dst, const char __user *src, long count)
if (unlikely(count <= 0))
return 0;
+ src = untagged_addr(src);
+
max_addr = user_addr_max();
src_addr = (unsigned long)src;
if (likely(src_addr < max_addr)) {
diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
index 60d0bbda8f5e..8b5f56466e00 100644
--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -108,6 +108,8 @@ long strnlen_user(const char __user *str, long count)
if (unlikely(count <= 0))
return 0;
+ str = untagged_addr(str);
+
max_addr = user_addr_max();
src_addr = (unsigned long)str;
if (likely(src_addr < max_addr)) {
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 1/8] arm64: add type casts to untagged_addr macro
From: Andrey Konovalov @ 2018-12-10 12:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 07c34087bd5e..3c3864ba3cc1 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -101,7 +101,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
* up with a tagged userland pointer. Clear the tag to get a sane pointer to
* pass on to access_ok(), for instance.
*/
-#define untagged_addr(addr) sign_extend64(addr, 55)
+#define untagged_addr(addr) \
+ ((__typeof__(addr))sign_extend64((u64)(addr), 55))
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 0/8] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2018-12-10 12:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
Right now the kernel is already able to handle user faults with tagged
pointers, due to these patches:
1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a
tagged pointer")
2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged
pointers")
3. 276e9327 ("arm64: entry: improve data abort handling of tagged
pointers")
When passing tagged pointers to syscalls, there's a special case of such a
pointer being passed to one of the memory syscalls (mmap, mprotect, etc.).
These syscalls don't do memory accesses but rather deal with memory
ranges, hence an untagged pointer is better suited.
This patchset extends tagged pointer support to non-memory syscalls. This
is done by reusing the untagged_addr macro to untag user pointers when the
kernel performs pointer checking to find out whether the pointer comes
from userspace (most notably in access_ok). The untagging is done only
when the pointer is being checked, the tag is preserved as the pointer
makes its way through the kernel.
One of the alternative approaches to untagging that was considered is to
completely strip the pointer tag as the pointer enters the kernel with
some kind of a syscall wrapper, but that won't work with the countless
number of different ioctl calls. With this approach we would need a custom
wrapper for each ioctl variation, which doesn't seem practical.
The following testing approaches has been taken to find potential issues
with user pointer untagging:
1. Static testing (with sparse [2] and separately with a custom static
analyzer based on Clang) to track casts of __user pointers to integer
types to find places where untagging needs to be done.
2. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running
a modified syzkaller version that passes tagged pointers to the kernel.
Based on the results of the testing the requried patches have been added
to the patchset.
This patchset has been merged into the Pixel 2 kernel tree and is now
being used to enable testing of Pixel 2 phones with HWASan.
This patchset is a prerequisite for ARM's memory tagging hardware feature
support [3].
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
[2] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292
[3] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a
Changes in v9:
- Rebased onto 4.20-rc6.
- Used u64 instead of __u64 in type casts in the untagged_addr macro for
arm64.
- Added braces around (addr) in the untagged_addr macro for other arches.
Changes in v8:
- Rebased onto 65102238 (4.20-rc1).
- Added a note to the cover letter on why syscall wrappers/shims that untag
user pointers won't work.
- Added a note to the cover letter that this patchset has been merged into
the Pixel 2 kernel tree.
- Documentation fixes, in particular added a list of syscalls that don't
support tagged user pointers.
Changes in v7:
- Rebased onto 17b57b18 (4.19-rc6).
- Dropped the "arm64: untag user address in __do_user_fault" patch, since
the existing patches already handle user faults properly.
- Dropped the "usb, arm64: untag user addresses in devio" patch, since the
passed pointer must come from a vma and therefore be untagged.
- Dropped the "arm64: annotate user pointers casts detected by sparse"
patch (see the discussion to the replies of the v6 of this patchset).
- Added more context to the cover letter.
- Updated Documentation/arm64/tagged-pointers.txt.
Changes in v6:
1 From 502466b9652c57a23af3bd72124144319212f30b Mon Sep 17 00:00:00 2001
- Added annotations for user pointer casts found by sparse.
1 From 502466b9652c57a23af3bd72124144319212f30b Mon Sep 17 00:00:00 2001
- Rebased onto 050cdc6c (4.19-rc1+).
1 From 502466b9652c57a23af3bd72124144319212f30b Mon Sep 17 00:00:00 2001
Changes in v5:
- Added 3 new patches that add untagging to places found with static
analysis.
- Rebased onto 44c929e1 (4.18-rc8).
Changes in v4:
- Added a selftest for checking that passing tagged pointers to the
kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).
Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.
Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.
Changes in v1:
- Rebased onto 4.17-rc1.
Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped "mm, arm64: untag user addresses in memory syscalls".
- Rebased onto 3eb2ce82 (4.16-rc7).
Reviewed-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Andrey Konovalov (8):
arm64: add type casts to untagged_addr macro
uaccess: add untagged_addr definition for other arches
arm64: untag user addresses in access_ok and __uaccess_mask_ptr
mm, arm64: untag user addresses in mm/gup.c
lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
fs, arm64: untag user address in copy_mount_options
arm64: update Documentation/arm64/tagged-pointers.txt
selftests, arm64: add a selftest for passing tagged pointers to kernel
Documentation/arm64/tagged-pointers.txt | 25 +++++++++++--------
arch/arm64/include/asm/uaccess.h | 14 +++++++----
fs/namespace.c | 2 +-
include/linux/uaccess.h | 4 +++
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
mm/gup.c | 4 +++
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile | 11 ++++++++
.../testing/selftests/arm64/run_tags_test.sh | 12 +++++++++
tools/testing/selftests/arm64/tags_test.c | 19 ++++++++++++++
11 files changed, 80 insertions(+), 16 deletions(-)
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 3/8] arm64: untag user addresses in access_ok and __uaccess_mask_ptr
From: Andrey Konovalov @ 2018-12-10 12:51 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
Kees Cook, Kate Stewart, Greg Kroah-Hartman, Andrew Morton,
Ingo Molnar, Kirill A . Shutemov, Shuah Khan, linux-arm-kernel,
linux-doc, linux-mm, linux-arch, linux-kselftest, linux-kernel
Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Andrey Konovalov,
Lee Smith, Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
Luc Van Oostenryck, Evgeniy Stepanov
In-Reply-To: <cover.1544445454.git.andreyknvl@google.com>
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers in access_ok and in __uaccess_mask_ptr,
before performing access validity checks.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 3c3864ba3cc1..d28c3b1314ce 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -104,7 +104,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
#define untagged_addr(addr) \
((__typeof__(addr))sign_extend64((u64)(addr), 55))
-#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok(type, addr, size) \
+ __range_ok(untagged_addr(addr), size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
@@ -236,7 +237,8 @@ static inline void uaccess_enable_not_uao(void)
/*
* Sanitise a uaccess pointer such that it becomes NULL if above the
- * current addr_limit.
+ * current addr_limit. In case the pointer is tagged (has the top byte set),
+ * untag the pointer before checking.
*/
#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
@@ -244,10 +246,11 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
void __user *safe_ptr;
asm volatile(
- " bics xzr, %1, %2\n"
+ " bics xzr, %3, %2\n"
" csel %0, %1, xzr, eq\n"
: "=&r" (safe_ptr)
- : "r" (ptr), "r" (current_thread_info()->addr_limit)
+ : "r" (ptr), "r" (current_thread_info()->addr_limit),
+ "r" (untagged_addr(ptr))
: "cc");
csdb();
--
2.20.0.rc2.403.gdbc3b29805-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] clk: sunxi-ng: a64: Allow parent change for VE clock
From: Maxime Ripard @ 2018-12-10 12:40 UTC (permalink / raw)
To: Jernej Skrabec
Cc: sboyd, mturquette, linux-sunxi, linux-kernel, wens, linux-clk,
linux-arm-kernel
In-Reply-To: <20181208180222.12608-1-jernej.skrabec@siol.net>
[-- Attachment #1.1: Type: text/plain, Size: 530 bytes --]
On Sat, Dec 08, 2018 at 07:02:22PM +0100, Jernej Skrabec wrote:
> Cedrus driver wants to set VE clock higher than it's possible without
> changing parent rate.
>
> Allow changing parent rate for VE clock, so clock rate can be set
> freely.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Stephen, Mike, could you apply that patch directly?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Sekhar Nori @ 2018-12-10 12:40 UTC (permalink / raw)
To: Nishanth Menon
Cc: mark.rutland, devicetree, ulf.hansson, Arnd Bergmann,
Tony Lindgren, linux-kernel, robh+dt, kishon, t-kristo,
Faiz Abbas, adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <20181210120647.i3ply3p7umvedb3u@akan>
Hi Nishanth,
On 10/12/18 5:36 PM, Nishanth Menon wrote:
> On 13:33-20181210, Sekhar Nori wrote:
>> On 08/12/18 9:24 PM, Nishanth Menon wrote:
>>> On 14:12-20181207, Faiz Abbas wrote:
>>>
>>>> +
>>>> +&sdhci0 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mmc0_pins_default>;
>>>> + bus-width = <8>;
>>>> + non-removable;
>>>> + ti,driver-strength-ohm = <50>;
>>>
>>> ^^
>>>
>>>> +};
>>>> +
>>>> +&sdhci1 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mmc1_pins_default>;
>>>> + ti,driver-strength-ohm = <50>;
>>>
>>> NAK.
>>>
>>> $ git checkout next-20181207
>>> $ git grep ti,driver-strength-ohm Documentation
>>> $
>>>
>>> Nada.. And.. I think "new phy binding" probably introduces this.
>>> [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185
>>>
>>> If your patches are'nt really ready, please send them as RFC, I am not
>>> really in a mood to track the status of every single driver subsystem.
>>>
>>> If your binding is not in linux next at the baremin, as far as I am
>>> concerned, this is not ready, and should be RFC.
>>
>> No, RFC does not say "do not merge" or "this has dependencies". RFC is
>> used to invite a stronger review when introducing a new concept. Its
>> fair game to apply patches marked RFC if maintainer is okay with the
>> content.
>
> True, fair enough.. RFC is request for comments. Anyways, that is
> besides the point.
>>
>> Dependencies are either noted in cover-letter or below the patch
>> tear-line. With what you are asking, looks like patches need to be
>> resubmitted once dependencies are cleared, even if there is no change in
>> the content itself. This will be additional work.
>
> Yes please. There would be other dts changes that are probably ready and
> I really wont be tracking everything happening on other drivers. If the
> binding is present at least in next, it is a good indication of things
> clean and ready to go.
Agree that bindings should be in linux-next before device-tree files are
merged.
>
>>
>> That said, if it makes life convenient for you, you can impose such a
>> rule for patches you need to handle. But I think it will take some
>> getting used for developers who send patches to you as I don't think
>> this is a norm elsewhere.
>>
>> Adding Tony and Arnd as well, in case I have missed some recently
>> accepted convention.
>
>
> I have'nt looked at any conventions, The style I prefer to follow when I do
> submissions: It is my job to get the bindings in, until then my actual
> dts is just "request for comments". Only after the bindings are merged
> do I formally submit dts - simply because I dont expect dts maintainer
> to track what happened to my driver's binding and discussions there of.
Ok.
>
> Seriously, is'nt it really reasonable for dts maintainer to check every
> single driver's development status in 15 different mailing lists?
> Because, it sounds like what you are asking. At least I wont have time
> for it..
>
>
> I really am curious how Arnd / Tony actually pull this one off.. If they
> have continous cron job for checking if your patch is ready... I doubt
> it..
I think you can rely on the author to tell you when something is
actually ready to be merged (and you can tell him/her to remind you).
For the review itself, doing it by having a look at the dependencies
mentioned in the cover letter (like available for this series) should be
good enough (I feel).
I am not sure if there is a need to post an "RFC version", and then
follow it up with an actual "PATCH version" once dependencies are
cleared though.
Thanks,
Sekhar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/8] KVM: arm64: Rework detection of SVE, !VHE systems
From: Will Deacon @ 2018-12-10 12:40 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Catalin Marinas,
Christoffer Dall, James Morse, kvmarm, linux-arm-kernel
In-Reply-To: <aff2750e-6746-3378-6d4d-dcbfc2028154@arm.com>
On Mon, Dec 10, 2018 at 10:28:05AM +0000, Marc Zyngier wrote:
> On 10/12/2018 10:13, Christoffer Dall wrote:
> > On Thu, Dec 06, 2018 at 05:31:20PM +0000, Marc Zyngier wrote:
> >> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> >> index 23774970c9df..1db4c15edcdd 100644
> >> --- a/virt/kvm/arm/arm.c
> >> +++ b/virt/kvm/arm/arm.c
> >> @@ -1640,8 +1640,10 @@ int kvm_arch_init(void *opaque)
> >> return -ENODEV;
> >> }
> >>
> >> - if (!kvm_arch_check_sve_has_vhe()) {
> >> - kvm_pr_unimpl("SVE system without VHE unsupported. Broken cpu?");
> >> + in_hyp_mode = is_kernel_in_hyp_mode();
> >> +
> >> + if (!in_hyp_mode && kvm_arch_requires_vhe()) {
> >> + kvm_pr_unimpl("CPU requiring VHE was booted in non-VHE mode");
> >
> > nit: The error message feels weird to me (are we reporting CPU bugs?)
> > and I'm not sure about the unimpl and I think there's a linse space
> > missing.
> >
> > How about:
> >
> > kvm_err("Cannot support this CPU in non-VHE mode, not initializing\n");
>
> Yup, works for me. Will, do you mind changing this message for me?
I pushed out an updated branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kvm/cortex-a76-erratum-1165522
which should address all of Christoffer's comments and add his tags.
I plan to merge that into for-next/core later today.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* ufs_qcom_dump_dbg_regs makes the kernel panic
From: Marc Gonzalez @ 2018-12-10 12:37 UTC (permalink / raw)
To: Jeffrey Hugo, Vivek Gautam, Bjorn Andersson, Andy Gross,
David Brown
Cc: MSM, Linux ARM
Hello,
When the kernel fails to init the UFSHC, it calls ufshcd_print_host_regs()
to help with debugging, which calls the dbg_register_dump hook.
ufs_qcom_dump_dbg_regs makes the kernel panic:
[ 3.715634] UFS_DBG_RD_REG_TXUC 000000a0: 00000000 00000000 00000000 00000000
[ 3.722750] UFS_DBG_RD_REG_TXUC 000000b0: 00000001 00000000 00000000 00000004
[ 3.729943] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 3.737000] Modules linked in:
[ 3.744371] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G S 4.20.0-rc4 #16
[ 3.747413] Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
[ 3.755295] pstate: 00000005 (nzcv daif -PAN -UAO)
[ 3.761978] pc : __memcpy_fromio+0x68/0x80
[ 3.766718] lr : ufshcd_dump_regs+0x50/0xb0
[ 3.770767] sp : ffff00000807ba00
[ 3.774830] x29: ffff00000807ba00 x28: 00000000fffffffb
[ 3.778344] x27: ffff0000089db068 x26: ffff8000f6e58000
[ 3.783728] x25: 000000000000000e x24: 0000000000000800
[ 3.789023] x23: ffff8000f6e587c8 x22: 0000000000000800
[ 3.794319] x21: ffff000008908368 x20: ffff8000f6e1ab80
[ 3.799615] x19: 000000000000006c x18: ffffffffffffffff
[ 3.804910] x17: 0000000000000000 x16: 0000000000000000
[ 3.810206] x15: ffff000009199648 x14: ffff000089244187
[ 3.815502] x13: ffff000009244195 x12: ffff0000091ab000
[ 3.820797] x11: 0000000005f5e0ff x10: ffff0000091998a0
[ 3.826093] x9 : 0000000000000000 x8 : ffff8000f6e1ac00
[ 3.831389] x7 : 0000000000000000 x6 : 0000000000000068
[ 3.836676] x5 : ffff8000f6e1abe8 x4 : 0000000000000000
[ 3.841971] x3 : ffff00000928c868 x2 : ffff8000f6e1abec
[ 3.847267] x1 : ffff00000928c868 x0 : ffff8000f6e1abe8
[ 3.852567] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
[ 3.857900] Call trace:
[ 3.864473] __memcpy_fromio+0x68/0x80
[ 3.866683] ufs_qcom_dump_dbg_regs+0x1c0/0x370
[ 3.870522] ufshcd_print_host_regs+0x168/0x190
[ 3.874946] ufshcd_init+0xd4c/0xde0
[ 3.879459] ufshcd_pltfrm_init+0x3c8/0x550
[ 3.883264] ufs_qcom_probe+0x24/0x60
[ 3.887188] platform_drv_probe+0x50/0xa0
[ 3.890993] really_probe+0x1f0/0x2a0
[ 3.894983] driver_probe_device+0x58/0x100
[ 3.898628] __driver_attach+0xd4/0xe0
[ 3.902617] bus_for_each_dev+0x74/0xd0
[ 3.906436] driver_attach+0x20/0x30
[ 3.910169] bus_add_driver+0x1ac/0x220
[ 3.913992] driver_register+0x60/0x110
[ 3.917540] __platform_driver_register+0x40/0x50
[ 3.921413] ufs_qcom_pltform_init+0x18/0x20
[ 3.926248] do_one_initcall+0x5c/0x180
[ 3.930593] kernel_init_freeable+0x198/0x244
[ 3.934156] kernel_init+0x10/0x110
[ 3.938629] ret_from_fork+0x10/0x20
[ 3.941940] Code: f2400842 54000100 8b020002 d503201f (39400023)
[ 3.945875] ---[ end trace 2d10f654364744f5 ]---
[ 3.951841] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 3.956528] SMP: stopping secondary CPUs
[ 5.005502] SMP: failed to stop secondary CPUs 2,7
[ 5.005648] Kernel Offset: disabled
[ 5.009292] CPU features: 0x2,21802008
[ 5.012676] Memory Limit: none
[ 5.016485] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
The problem appears to be on this line:
reg = ufs_qcom_get_debug_reg_offset(host, UFS_DBG_RD_REG_RXUC);
/* reg = 0x800 */
print_fn(hba, reg, 27, "UFS_DBG_RD_REG_RXUC ", priv);
I'm not sure what's going on, because the driver is supposed to map 0x2500 bytes.
(reg = <0x1da4000 0x2500>;)
Commenting out the last 4 dumps of ufs_qcom_print_hw_debug_reg_all() makes
the panic disappear, but the kernel just hangs after printing UFS_DBG_RD_REG_TXUC
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] Add support for STM32F4 SPI
From: Amelie DELAUNAY @ 2018-12-10 12:37 UTC (permalink / raw)
To: cezary.gapinski@gmail.com, Mark Brown, linux-spi@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring,
devicetree@vger.kernel.org
Cc: Mark Rutland, Alexandre TORGUE, Maxime Coquelin
In-Reply-To: <1544363636-12161-1-git-send-email-cezary.gapinski@gmail.com>
Hi Cezary,
On 12/9/18 2:53 PM, cezary.gapinski@gmail.com wrote:
> From: Cezary Gapinski <cezary.gapinski@gmail.com>
>
> This series of patches adds support for first generation of SPI interface
> for STM32F4 family.
>
First of all, thanks for adding STM32F4 SPI support.
> This version of driver is mostly different to STM32H7 one. Based on linux
> kernel I2C drivers for STM32 where drivers were splited into STM32F4 and
> STM32F7 family the same approach seems to be sufficient for SPI STM32
> drivers. Therefore STM32H7 driver was moved to spi-stm32h7.c file and
> register and functions were renamed to be more specific to STM32H7.
>
You're right, STM32F4 SPI is slightly different from STM32H7 one:
register map/bits offsets are different and STM32H7 has an RX and TX FIFO.
But if you have a look on STM32F7 SPI [1], you'll see that STM32F7 SPI
is based on STM32F4 SPI with new features (data frames & FIFOs) also
available on STM32H7 SPI.
That's why STM32H7 SPI driver was called spi-stm32. The goal was to use
compatible & match data to differentiate each STM32Fx specificities.
You can have a look on how it is managed in drivers/rtc/rtc-stm32.c (the
same driver covers 2 HW version of STM32 RTC), or in
drivers/iio/dac/stm32-dac-core.c and stm32-dac.c (the same driver also
covers 2 HW version of STM32 DAC).
As your spi-stm32f4.c file is highly based on the existing spi-stm32.c
file, I think that common code could be factored and specificities could
be handled with compatible and match data.
Regards,
Amelie
[1]
https://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf
> For current version master mode with full-duplex and 8/16 bit data frame
> format are supported. There is no TX and RX FIFOs like in STM32H7.
> DMA capabilility is supported for messages longer than arbitrary number
> of bytes (that is set already to 16 bytes) when TX and RX channels are
> set at the same time.
>
> Cezary Gapinski (5):
> spi: stm32: rename STM32 SPI registers and functions to STM32H7
> spi: stm32: rename spi-stm32 to spi-stm32h7
> spi: stm32: add driver for STM32F4 controller
> ARM: dts: stm32: add SPI support on STM32F429 SoC
> spi: stm32: add description about STM32F4 bindings
>
> .../devicetree/bindings/spi/spi-stm32.txt | 9 +-
> arch/arm/boot/dts/stm32f429.dtsi | 60 +
> drivers/spi/Kconfig | 18 +-
> drivers/spi/Makefile | 3 +-
> drivers/spi/spi-stm32.c | 1322 -------------------
> drivers/spi/spi-stm32f4.c | 1002 +++++++++++++++
> drivers/spi/spi-stm32h7.c | 1340 ++++++++++++++++++++
> 7 files changed, 2424 insertions(+), 1330 deletions(-)
> delete mode 100644 drivers/spi/spi-stm32.c
> create mode 100644 drivers/spi/spi-stm32f4.c
> create mode 100644 drivers/spi/spi-stm32h7.c
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] opp: Add API for getting voltage from supplies
From: Nick Fan @ 2018-12-10 12:36 UTC (permalink / raw)
To: Viresh Kumar
Cc: Nishanth Menon, Chiawen.Lee, srv_heupstream, linux-pm,
Stephen Boyd, Viresh Kumar, erin.lo, Rafael J. Wysocki,
linux-kernel, tfiga, linux-mediatek, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <20181204082158.rb7uzdiwmcotwoxh@vireshk-i7>
On Tue, 2018-12-04 at 13:51 +0530, Viresh Kumar wrote:
> On 04-12-18, 14:59, Nick Fan wrote:
> > Add API to get voltage for multiple supplies from opp table
>
> And who needs to use this new API ? It would be better to add the user in the
> same series to make sure this really gets used.
This new API would be required when handling multiple regulators.
You can check the example 4 in
Documentation/devicetree/bindings/opp/opp.txt for multiple regulators.
When we specify multiple regulator voltages in device tree, we are not
able to access the secondary supply voltages.
Because the dev_pm_opp_get_voltage only returns the first supply
voltages, this new API is required to get the specific supply.
>
> > Signed-off-by: Nick Fan <Nick.Fan@mediatek.com>
> > ---
> > drivers/opp/core.c | 28 ++++++++++++++++++++++++++++
> > include/linux/pm_opp.h | 3 +++
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index 2c2df4e..ee73546 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -113,6 +113,34 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
> > EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
> >
> > /**
> > + * dev_pm_opp_get_voltage_supply() - Gets the voltage corresponding to an opp
> > + * with index
> > + * @opp: opp for which voltage has to be returned for
> > + * @index: index to specify the returned supplies
> > + *
> > + * Return: voltage in micro volt corresponding to the opp with index, else
> > + * return 0
> > + *
> > + * This is useful for devices with multiple power supplies.
> > + */
> > +unsigned long dev_pm_opp_get_voltage_supply(struct dev_pm_opp *opp,
> > + unsigned int index)
>
> How will the users of this API get the index ?
For the users who only use one supply, they can use
dev_pm_opp_get_voltage to get the voltage data from an opp.
But if the users who use more than one supply, they will need this API
to get their voltage data from OPP.
The users should know about the supply count while creating opp table by
using dev_pm_opp_set_regulators function.
By using this API, the users can get the voltages by using index to
specify which supplies they want.
The following is a simple example to get multiple regulators by this
API.
for (i = 0; i < regulator_num; i++)
target_volt[i] = dev_pm_opp_get_voltage_supply(opp, i);
>
> > +{
> > + if (IS_ERR_OR_NULL(opp)) {
> > + pr_err("%s: Invalid parameters\n", __func__);
> > + return 0;
> > + }
> > +
> > + if (index >= opp->opp_table->regulator_count) {
> > + pr_err("%s: Invalid supply index: %u\n", __func__, index);
> > + return 0;
> > + }
> > +
> > + return opp->supplies[index].u_volt;
>
Nick Fan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Biju Das @ 2018-12-10 12:35 UTC (permalink / raw)
To: Simon Horman
Cc: linux-rtc@vger.kernel.org, Fabrizio Castro, Alexandre Belloni,
Geert Uytterhoeven, Magnus Damm, Russell King,
linux-renesas-soc@vger.kernel.org, Chris Paterson,
Srinivas Kandagatla, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210121340.iuwyq5myk4woezpg@verge.net.au>
Hi Simon,
Thanks for the feedback.
> Subject: Re: [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in
> shmobile_defconfig
>
> On Fri, Dec 07, 2018 at 11:27:45AM +0000, Biju Das wrote:
> > The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
> > support enable the driver in the shmobile_defconfig multiplatform
> > configuration.
> >
> > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks, applied for v4.22.
>
> Is a similar change for multi_v7_defconfig also appropriate?
Will send a separate patch for adding it to the "multi_v7_defconfig"
CONFIG_RTC_DRV_PCF85363=m
Regards,
Biju
[https://www2.renesas.eu/media/email/unicef.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 02/12] clk: mediatek: add new clkmux register API
From: Nicolas Boichat @ 2018-12-10 12:30 UTC (permalink / raw)
To: Weiyi Lu
Cc: Rob Herring, srv_heupstream, jamesjj.liao, sboyd, lkml, stable,
Fan Chen, linux-mediatek, Matthias Brugger, owen.chen, linux-clk,
linux-arm Mailing List
In-Reply-To: <20181210073240.32278-4-weiyi.lu@mediatek.com>
On Mon, Dec 10, 2018 at 3:33 PM Weiyi Lu <weiyi.lu@mediatek.com> wrote:
>
> From: Owen Chen <owen.chen@mediatek.com>
>
> On both MT8183 & MT6765, there add "set/clr" register for
> each clkmux setting, and one update register to trigger value change.
> It is designed to prevent read-modify-write racing issue.
> The sw design need to add a new API to handle this hw change with
> a new mtk_clk_mux/mtk_mux struct in new file "clk-mux.c", "clk-mux.h".
>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> drivers/clk/mediatek/Makefile | 3 +-
> drivers/clk/mediatek/clk-mux.c | 229 +++++++++++++++++++++++++++++++++
> drivers/clk/mediatek/clk-mux.h | 101 +++++++++++++++
> 3 files changed, 332 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/mediatek/clk-mux.c
> create mode 100644 drivers/clk/mediatek/clk-mux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 844b55d2770d..00e4d405231e 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o clk-cpumux.o reset.o
> +obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o clk-cpumux.o reset.o clk-mux.o
> +
> obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
> obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
> obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
> diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
> new file mode 100644
> index 000000000000..efbbb35eb185
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mux.c
> @@ -0,0 +1,229 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen <owen.chen@mediatek.com>
> + */
> +
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/mfd/syscon.h>
> +
> +#include "clk-mtk.h"
> +#include "clk-mux.h"
> +
> +static inline struct mtk_clk_mux *to_mtk_clk_mux(struct clk_hw *hw)
> +{
> + return container_of(hw, struct mtk_clk_mux, hw);
> +}
> +
> +static int mtk_clk_mux_enable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->gate_shift);
> +
> + return regmap_update_bits(mux->regmap, mux->mux_ofs, mask, ~mask);
> +}
> +
> +static void mtk_clk_mux_disable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->gate_shift);
> +
> + regmap_update_bits(mux->regmap, mux->mux_ofs, mask, mask);
> +}
> +
> +static int mtk_clk_mux_enable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> +
> + return regmap_write(mux->regmap, mux->mux_clr_ofs,
> + BIT(mux->gate_shift));
> +}
> +
> +static void mtk_clk_mux_disable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> +
> + regmap_write(mux->regmap, mux->mux_set_ofs, BIT(mux->gate_shift));
> +}
> +
> +static int mtk_clk_mux_is_enabled(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &val);
> +
> + return (val & BIT(mux->gate_shift)) == 0;
> +}
> +
> +static u8 mtk_clk_mux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &val);
> + val = (val >> mux->mux_shift) & mask;
> +
> + return val;
> +}
> +
> +static int mtk_clk_mux_set_parent_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + unsigned long flags;
> +
> + if (mux->lock)
> + spin_lock_irqsave(mux->lock, flags);
> + else
> + __acquire(mux->lock);
> +
> + regmap_update_bits(mux->regmap, mux->mux_ofs, mask,
> + index << mux->mux_shift);
> +
> + if (mux->lock)
> + spin_unlock_irqrestore(mux->lock, flags);
> + else
> + __release(mux->lock);
> +
> + return 0;
> +}
> +
> +static int mtk_clk_mux_set_parent_setclr_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->mux_width - 1, 0);
> + u32 val, orig;
> + unsigned long flags;
> +
> + if (mux->lock)
> + spin_lock_irqsave(mux->lock, flags);
> + else
> + __acquire(mux->lock);
> +
> + regmap_read(mux->regmap, mux->mux_ofs, &orig);
> + val = (orig & ~(mask << mux->mux_shift)) | (index << mux->mux_shift);
> +
> + if (val != orig) {
> + regmap_write(mux->regmap, mux->mux_clr_ofs,
> + mask << mux->mux_shift);
> + regmap_write(mux->regmap, mux->mux_set_ofs,
> + index << mux->mux_shift);
> +
> + if (mux->upd_shift >= 0)
> + regmap_write(mux->regmap, mux->upd_ofs,
> + BIT(mux->upd_shift));
> + }
> +
> + if (mux->lock)
> + spin_unlock_irqrestore(mux->lock, flags);
> + else
> + __release(mux->lock);
> +
> + return 0;
> +}
> +
> +const struct clk_ops mtk_mux_ops = {
> + .get_parent = mtk_clk_mux_get_parent,
> + .set_parent = mtk_clk_mux_set_parent_lock,
> +};
> +
> +const struct clk_ops mtk_mux_clr_set_upd_ops = {
> + .get_parent = mtk_clk_mux_get_parent,
> + .set_parent = mtk_clk_mux_set_parent_setclr_lock,
> +};
> +
> +const struct clk_ops mtk_mux_gate_ops = {
> + .enable = mtk_clk_mux_enable,
> + .disable = mtk_clk_mux_disable,
> + .is_enabled = mtk_clk_mux_is_enabled,
> + .get_parent = mtk_clk_mux_get_parent,
> + .set_parent = mtk_clk_mux_set_parent_lock,
> +};
> +
> +const struct clk_ops mtk_mux_gate_clr_set_upd_ops = {
> + .enable = mtk_clk_mux_enable_setclr,
> + .disable = mtk_clk_mux_disable_setclr,
> + .is_enabled = mtk_clk_mux_is_enabled,
> + .get_parent = mtk_clk_mux_get_parent,
> + .set_parent = mtk_clk_mux_set_parent_setclr_lock,
> +};
> +
> +struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
> + struct regmap *regmap,
> + spinlock_t *lock)
> +{
> + struct mtk_clk_mux *mtk_mux;
I'd call this variable clk_mux.
> + struct clk_init_data init;
> + struct clk *clk;
> +
> + mtk_mux = kzalloc(sizeof(*mtk_mux), GFP_KERNEL);
> + if (!mtk_mux)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = mux->name;
> + init.flags = mux->flags | CLK_SET_RATE_PARENT;
> + init.parent_names = mux->parent_names;
> + init.num_parents = mux->num_parents;
> + init.ops = mux->ops;
> +
> + mtk_mux->regmap = regmap;
> + mtk_mux->name = mux->name;
> + mtk_mux->mux_ofs = mux->mux_ofs;
> + mtk_mux->mux_set_ofs = mux->set_ofs;
> + mtk_mux->mux_clr_ofs = mux->clr_ofs;
> + mtk_mux->upd_ofs = mux->upd_ofs;
> + mtk_mux->mux_shift = mux->mux_shift;
> + mtk_mux->mux_width = mux->mux_width;
> + mtk_mux->gate_shift = mux->gate_shift;
> + mtk_mux->upd_shift = mux->upd_shift;
These copies seem a bit wasteful. If the lifetime of the objects are
the same, can you just keep a pointer to struct mtk_mux in struct
mtk_clk_mux?
If not, maybe move all the settings to a "params" structure or
something like that, so we can do a simpler memcpy?
> +
> + mtk_mux->lock = lock;
> + mtk_mux->hw.init = &init;
> +
> + clk = clk_register(NULL, &mtk_mux->hw);
> + if (IS_ERR(clk)) {
> + kfree(mtk_mux);
> + return clk;
> + }
> +
> + return clk;
> +}
> +
> +int mtk_clk_register_muxes(const struct mtk_mux *muxes,
> + int num, struct device_node *node,
> + spinlock_t *lock,
> + struct clk_onecell_data *clk_data)
> +{
> + struct regmap *regmap;
> + struct clk *clk;
> + int i;
> +
> + regmap = syscon_node_to_regmap(node);
> + if (IS_ERR(regmap)) {
> + pr_err("Cannot find regmap for %pOF: %ld\n", node,
> + PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + for (i = 0; i < num; i++) {
> + const struct mtk_mux *mux = &muxes[i];
> +
> + if (IS_ERR_OR_NULL(clk_data->clks[mux->id])) {
> + clk = mtk_clk_register_mux(mux, regmap, lock);
> +
> + if (IS_ERR(clk)) {
> + pr_err("Failed to register clk %s: %ld\n",
> + mux->name, PTR_ERR(clk));
> + continue;
> + }
> +
> + clk_data->clks[mux->id] = clk;
> + }
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/clk/mediatek/clk-mux.h b/drivers/clk/mediatek/clk-mux.h
> new file mode 100644
> index 000000000000..830a6117e670
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mux.h
> @@ -0,0 +1,101 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen <owen.chen@mediatek.com>
> + */
> +
> +#ifndef __DRV_CLK_MTK_MUX_H
> +#define __DRV_CLK_MTK_MUX_H
> +
> +#include <linux/clk-provider.h>
> +
> +struct mtk_clk_mux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> +
> + const char *name;
> +
> + u32 mux_set_ofs;
> + u32 mux_clr_ofs;
> + u32 mux_ofs;
> + u32 upd_ofs;
> +
> + u8 mux_shift;
> + u8 mux_width;
> + u8 gate_shift;
> + s8 upd_shift;
> +
> + spinlock_t *lock;
> +};
> +
> +struct mtk_mux {
> + int id;
> + const char *name;
> + const char * const *parent_names;
> + unsigned int flags;
> +
> + u32 mux_ofs;
> + u32 set_ofs;
> + u32 clr_ofs;
> + u32 upd_ofs;
> +
> + u8 mux_shift;
> + u8 mux_width;
> + u8 gate_shift;
> + s8 upd_shift;
> +
> + const struct clk_ops *ops;
> +
> + signed char num_parents;
> +};
> +
> +extern const struct clk_ops mtk_mux_ops;
> +extern const struct clk_ops mtk_mux_clr_set_upd_ops;
> +extern const struct clk_ops mtk_mux_gate_ops;
> +extern const struct clk_ops mtk_mux_gate_clr_set_upd_ops;
> +
> +#define GATE_CLR_SET_UPD_FLAGS(_id, _name, _parents, _mux_ofs, \
> + _mux_set_ofs, _mux_clr_ofs, _shift, _width, \
> + _gate, _upd_ofs, _upd, _flags, _ops) { \
> + .id = _id, \
> + .name = _name, \
> + .mux_ofs = _mux_ofs, \
> + .set_ofs = _mux_set_ofs, \
> + .clr_ofs = _mux_clr_ofs, \
> + .upd_ofs = _upd_ofs, \
> + .mux_shift = _shift, \
> + .mux_width = _width, \
> + .gate_shift = _gate, \
> + .upd_shift = _upd, \
> + .parent_names = _parents, \
> + .num_parents = ARRAY_SIZE(_parents), \
> + .flags = _flags, \
> + .ops = &_ops, \
> + }
> +
> +#define MUX_GATE_CLR_SET_UPD_FLAGS(_id, _name, _parents, _mux_ofs, \
> + _mux_set_ofs, _mux_clr_ofs, _shift, _width, \
> + _gate, _upd_ofs, _upd, _flags) \
> + GATE_CLR_SET_UPD_FLAGS(_id, _name, _parents, _mux_ofs, \
> + _mux_set_ofs, _mux_clr_ofs, _shift, _width, \
> + _gate, _upd_ofs, _upd, _flags, \
> + mtk_mux_gate_clr_set_upd_ops)
> +
> +#define MUX_GATE_CLR_SET_UPD(_id, _name, _parents, _mux_ofs, \
> + _mux_set_ofs, _mux_clr_ofs, _shift, _width, \
> + _gate, _upd_ofs, _upd) \
> + MUX_GATE_CLR_SET_UPD_FLAGS(_id, _name, _parents, \
> + _mux_ofs, _mux_set_ofs, _mux_clr_ofs, _shift, \
> + _width, _gate, _upd_ofs, _upd, \
> + CLK_SET_RATE_PARENT)
> +
> +struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
> + struct regmap *regmap,
> + spinlock_t *lock);
> +
> +int mtk_clk_register_muxes(const struct mtk_mux *muxes,
> + int num, struct device_node *node,
> + spinlock_t *lock,
> + struct clk_onecell_data *clk_data);
> +
> +#endif /* __DRV_CLK_MTK_MUX_H */
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/7] drm: Split out drm_probe_helper.h
From: Neil Armstrong @ 2018-12-10 12:30 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics Development
Cc: linux-samsung-soc, nouveau, Daniel Vetter, linux-arm-msm, etnaviv,
DRI Development, virtualization, linux-renesas-soc,
linux-rockchip, linux-mediatek, amd-gfx, linux-amlogic,
linux-tegra, spice-devel, xen-devel, freedreno, linux-stm32,
linux-arm-kernel
In-Reply-To: <20181210101133.5364-1-daniel.vetter@ffwll.ch>
On 10/12/2018 11:11, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers. And indeed, all atomic drivers are now free of
> drm_crtc_helper.h includes.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: virtualization@lists.linux-foundation.org
> Cc: etnaviv@lists.freedesktop.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-amlogic@lists.infradead.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: spice-devel@lists.freedesktop.org
> Cc: amd-gfx@lists.freedesktop.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-rockchip@lists.infradead.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-tegra@vger.kernel.org
> Cc: xen-devel@lists.xen.org
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +-
> .../display/amdgpu_dm/amdgpu_dm_services.c | 2 +-
> drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +-
> drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
> drivers/gpu/drm/arc/arcpgu_sim.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +-
> drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
> drivers/gpu/drm/arm/malidp_drv.c | 2 +-
> drivers/gpu/drm/arm/malidp_mw.c | 2 +-
> drivers/gpu/drm/armada/armada_510.c | 2 +-
> drivers/gpu/drm/armada/armada_crtc.c | 2 +-
> drivers/gpu/drm/armada/armada_drv.c | 2 +-
> drivers/gpu/drm/armada/armada_fb.c | 2 +-
> drivers/gpu/drm/ast/ast_drv.c | 1 +
> drivers/gpu/drm/ast/ast_mode.c | 1 +
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +-
> drivers/gpu/drm/bochs/bochs_drv.c | 1 +
> drivers/gpu/drm/bochs/bochs_kms.c | 1 +
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +-
> .../drm/bridge/analogix/analogix_dp_core.c | 2 +-
> drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
> .../bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/panel.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
> drivers/gpu/drm/bridge/tc358764.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c | 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_drv.c | 1 +
> drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
> drivers/gpu/drm/drm_atomic_helper.c | 1 -
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> drivers/gpu/drm/drm_probe_helper.c | 2 +-
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +-
> drivers/gpu/drm/gma500/psb_intel_drv.h | 1 +
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +-
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
> .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
> drivers/gpu/drm/i2c/ch7006_priv.h | 2 +-
> drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_crt.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +-
> drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
> drivers/gpu/drm/imx/imx-ldb.c | 2 +-
> drivers/gpu/drm/imx/imx-tve.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
> drivers/gpu/drm/imx/parallel-display.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_dpi.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_crtc.c | 2 +-
> drivers/gpu/drm/meson/meson_drv.c | 2 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c | 2 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c | 2 +-
> .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 2 +-
> .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 2 +-
> drivers/gpu/drm/msm/msm_drv.h | 2 +-
> drivers/gpu/drm/msm/msm_fb.c | 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 1 +
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
> drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> drivers/gpu/drm/omapdrm/omap_connector.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
> drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_display.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.c | 3 +-
> drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
> drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
> drivers/gpu/drm/radeon/radeon_acpi.c | 1 +
> drivers/gpu/drm/radeon/radeon_connectors.c | 1 +
> drivers/gpu/drm/radeon/radeon_device.c | 1 +
> drivers/gpu/drm/radeon/radeon_display.c | 1 +
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 1 +
> drivers/gpu/drm/radeon/radeon_drv.c | 1 +
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 +
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_rgb.c | 2 +-
> drivers/gpu/drm/sti/sti_crtc.c | 2 +-
> drivers/gpu/drm/sti/sti_drv.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c | 2 +-
> drivers/gpu/drm/sti/sti_hda.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_tvout.c | 2 +-
> drivers/gpu/drm/stm/drv.c | 2 +-
> drivers/gpu/drm/stm/ltdc.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
> drivers/gpu/drm/tegra/drm.h | 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/hub.c | 2 +-
> drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +-
> drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
> drivers/gpu/drm/tve200/tve200_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_connector.c | 1 +
> drivers/gpu/drm/udl/udl_drv.c | 1 +
> drivers/gpu/drm/udl/udl_main.c | 1 +
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_dpi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> drivers/gpu/drm/vc4/vc4_vec.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
> drivers/gpu/drm/vkms/vkms_crtc.c | 2 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> drivers/gpu/drm/vkms/vkms_output.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +-
> drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_conn.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> drivers/gpu/drm/zte/zx_tvenc.c | 2 +-
> drivers/gpu/drm/zte/zx_vga.c | 2 +-
> drivers/gpu/drm/zte/zx_vou.c | 2 +-
> drivers/staging/vboxvideo/vbox_irq.c | 2 +-
> drivers/staging/vboxvideo/vbox_mode.c | 2 +-
> include/drm/drm_crtc_helper.h | 16 ------
> include/drm/drm_probe_helper.h | 50 +++++++++++++++++++
> 208 files changed, 256 insertions(+), 200 deletions(-)
[...]
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c
> index 75d97f1b2e8f..ec573c04206b 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -30,7 +30,7 @@
> #include <drm/drm_atomic.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_flip_work.h>
> -#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_probe_helper.h>
>
> #include "meson_crtc.h"
> #include "meson_plane.h"
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 3ee4d4a4ecba..6b29447fd09e 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -31,7 +31,7 @@
> #include <drm/drm_atomic.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_flip_work.h>
> -#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_probe_helper.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_gem_cma_helper.h>
> #include <drm/drm_gem_framebuffer_helper.h>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 807111ebfdd9..b6299f3f4310 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -27,7 +27,7 @@
>
> #include <drm/drmP.h>
> #include <drm/drm_edid.h>
> -#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_probe_helper.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/bridge/dw_hdmi.h>
>
> diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c b/drivers/gpu/drm/meson/meson_venc_cvbs.c
> index f7945bae3b4a..64de3a7026d0 100644
> --- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
> +++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
> @@ -27,7 +27,7 @@
>
> #include <drm/drmP.h>
> #include <drm/drm_edid.h>
> -#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_probe_helper.h>
> #include <drm/drm_atomic_helper.h>
>
> #include "meson_venc_cvbs.h"
[...]
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 0ee9a96b70da..a6d520d5b6ca 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -58,20 +58,4 @@ int drm_helper_connector_dpms(struct drm_connector *connector, int mode);
> void drm_helper_resume_force_mode(struct drm_device *dev);
> int drm_helper_force_disable_all(struct drm_device *dev);
>
> -/* drm_probe_helper.c */
> -int drm_helper_probe_single_connector_modes(struct drm_connector
> - *connector, uint32_t maxX,
> - uint32_t maxY);
> -int drm_helper_probe_detect(struct drm_connector *connector,
> - struct drm_modeset_acquire_ctx *ctx,
> - bool force);
> -void drm_kms_helper_poll_init(struct drm_device *dev);
> -void drm_kms_helper_poll_fini(struct drm_device *dev);
> -bool drm_helper_hpd_irq_event(struct drm_device *dev);
> -void drm_kms_helper_hotplug_event(struct drm_device *dev);
> -
> -void drm_kms_helper_poll_disable(struct drm_device *dev);
> -void drm_kms_helper_poll_enable(struct drm_device *dev);
> -bool drm_kms_helper_is_poll_worker(void);
> -
> #endif
> diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
> new file mode 100644
> index 000000000000..96c060c16a1e
> --- /dev/null
> +++ b/include/drm/drm_probe_helper.h
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright © 2006 Keith Packard
> + * Copyright © 2007-2008 Dave Airlie
> + * Copyright © 2007-2008 Intel Corporation
> + * Jesse Barnes <jesse.barnes@intel.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __DRM_PROBE_HELPER_H__
> +#define __DRM_PROBE_HELPER_H__
> +
> +#include <linux/types.h>
> +
> +struct drm_connector;
> +struct drm_device;
> +struct drm_modeset_acquire_ctx;
> +
> +int drm_helper_probe_single_connector_modes(struct drm_connector
> + *connector, uint32_t maxX,
> + uint32_t maxY);
> +int drm_helper_probe_detect(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool force);
> +void drm_kms_helper_poll_init(struct drm_device *dev);
> +void drm_kms_helper_poll_fini(struct drm_device *dev);
> +bool drm_helper_hpd_irq_event(struct drm_device *dev);
> +void drm_kms_helper_hotplug_event(struct drm_device *dev);
> +
> +void drm_kms_helper_poll_disable(struct drm_device *dev);
> +void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
> +
> +#endif
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Qualcomm Driver updates for 4.21 - Part 2
From: Stanimir Varbanov @ 2018-12-10 12:20 UTC (permalink / raw)
To: Andy Gross, arm
Cc: Arnd Bergmann, linux-arm-msm, linux-kernel, Bjorn Andersson,
Kevin Hilman, Olof Johansson, linux-arm-kernel
In-Reply-To: <1544245994-4228-2-git-send-email-andy.gross@linaro.org>
Hi Andy,
On 12/8/18 7:13 AM, Andy Gross wrote:
> The following changes since commit b601f73130a375c912d9f2ec93c5f3cea5d6a3da:
>
> drm: msm: Check cmd_db_read_aux_data() for failure (2018-11-29 17:41:53 -0600)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.21-2
>
> for you to fetch changes up to 92def04bd7b46f5b186f985d5c9d3804858c3c2f:
>
> MAINTAINERS: Change Todor Tomov's email address (2018-12-05 16:45:34 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based Driver Updates for v4.21 Part 2
>
> * Fix MAINTAINERS email address for Todor
> * Fix SCM compilation error
>
> ----------------------------------------------------------------
> Jonathan Marek (1):
> firmware: qcom: scm: fix compilation error when disabled
>
> Todor Tomov (1):
> MAINTAINERS: Change Todor Tomov's email address
I saw this patch is applied also in media_tree.git, not sure that is
problem though.
--
regards,
Stan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Simon Horman @ 2018-12-10 12:13 UTC (permalink / raw)
To: Biju Das
Cc: linux-rtc, Fabrizio Castro, Alexandre Belloni, Geert Uytterhoeven,
Magnus Damm, Russell King, linux-renesas-soc, Chris Paterson,
Srinivas Kandagatla, linux-arm-kernel
In-Reply-To: <1544182066-31528-5-git-send-email-biju.das@bp.renesas.com>
On Fri, Dec 07, 2018 at 11:27:45AM +0000, Biju Das wrote:
> The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
> support enable the driver in the shmobile_defconfig multiplatform
> configuration.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied for v4.22.
Is a similar change for multi_v7_defconfig also appropriate?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
From: Boris Brezillon @ 2018-12-10 12:11 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, robh@kernel.org,
linux-kernel@vger.kernel.org, Schrempf Frieder,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
broonie@kernel.org, linux-mtd@lists.infradead.org,
computersforpeace@gmail.com, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB57269A32C1FF1592F117B97799A50@VI1PR04MB5726.eurprd04.prod.outlook.com>
On Mon, 10 Dec 2018 11:25:55 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Boris,
>
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > Sent: Monday, December 10, 2018 4:39 PM
> > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> > Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; linux-
> > mtd@lists.infradead.org; marek.vasut@gmail.com; broonie@kernel.org; linux-
> > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org;
> > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm-
> > kernel@lists.infradead.org; computersforpeace@gmail.com; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
> >
> > On Mon, 10 Dec 2018 10:59:54 +0000
> > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> >
> > > Hi Boris,
> > >
> > > > -----Original Message-----
> > > > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > > > Sent: Monday, December 10, 2018 4:20 PM
> > > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> > > > Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; linux-
> > > > mtd@lists.infradead.org; marek.vasut@gmail.com; broonie@kernel.org;
> > > > linux- spi@vger.kernel.org; devicetree@vger.kernel.org;
> > > > robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org;
> > > > linux-arm- kernel@lists.infradead.org; computersforpeace@gmail.com;
> > > > linux- kernel@vger.kernel.org
> > > > Subject: Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI
> > > > controller
> > > >
> > > > On Mon, 10 Dec 2018 10:43:56 +0000
> > > > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> > > >
> > > > > > > Thus, in LUT preparation we have assigned only the base address.
> > > > > > > Now if I have assigned ahb_buf_size to FSPI_FLSHXXCR0 register
> > > > > > > then for
> > > > > > read/write data beyond limit of ahb_buf_size offset I get data corruption.
> > > > > >
> > > > > > Why would you do that? We have the ->adjust_op_size() exactly
> > > > > > for this reason, so, if someone tries to do a spi_mem_op with
> > > > > > data.nbytes > ahb_buf_size you should return an error.
> > > > > >
> > > > > Let me explain my implementation with example. If I have to write
> > > > > data of size
> > > > 0x100 bytes at offset 0x1200 for CS1, I would program as below:
> > > > > In func nxp_fspi_select_mem(), would set value of controller
> > > > > address space
> > > > size, memmap_phy_size, to FSPI_FLSHA2CR0 and rest all FSPI_FLSHXXCR0 as
> > 0.
> > > > > Value of memmap_phy_size is 0x10000000 i.e. 256 MB for my
> > > > > LX2160ARDB
> > > > target.
> > > > > Then in nxp_fspi_prepare_lut(), I would prepare LUT ADDR with
> > > > > address length
> > > > requirement 3/4 byte for NOR or 1/2/3/4 bytes for NAND flash.
> > > > > Also for LUT_NXP_WRITE would program data bytes as 0.
> > > > >
> > > > > Then inside func nxp_fspi_do_op(), set register FSPI_IPCR0 as the
> > > > > address offset i.e. 0x1200 and in register FSPI_IPCR1 program the
> > > > > data size to write i.e. 0x100
> > > > >
> > > > > If, as suggested if I tries to mark value of register
> > > > > FSPI_FLSHA2CR0 equal to
> > > > ahb_buf_size (0x800), then access for address 0x1200 gives me wrong
> > > > data. This is because as per the controller specification access to
> > > > flash connected at CS1 can be performed under range of FSPI_ FLSHA1CR0
> > and FSPI_ FLSHA2CR0.
> > > >
> > > > Don't you have a way to set an offset to apply to the address
> > > > accessed through the AHB? And if you don't, how will it work if your
> > > > mapping is smaller than the flash size?
> > >
> > > Write operations are triggered using IP commands instead of AHB command.
> > > For Read AHB command is used and in this we are adding the offset when
> > performing memcpy_fromIO operation
> > > memcpy_fromio(op->data.buf.in, (f->ahb_addr + op->addr.val),
> > > len);
> > >
> > > AHB/IP operations are independent of the way how CS got selected. CS
> > selection depends, e.g. CS1 on the value of register FSPI_FLSHA1CR0 and
> > FSPI_FLSHA2CR0.
> > >
> > > Mapping can never going to be smaller than the connected flash size as per
> > discussion with the Board design team and if it's possible by user manually
> > changes the non-soldered part then flash area beyond complete mapping is not
> > accessible.
> > > On LX2160ARDB, with mapping of 256MB, for now we are having 4 flash
> > devices connected with size as 64 MB. If user wants he can have only one single
> > flash with flash size of 256MB.
> >
> > Given that the dirmap interface has now been merged and the MTD side of
> > things is soon to be merged, I'd recommend you to implement it in your
> > v6 and only use non-AHB accesses for the ->exec_op() implementation.
>
> This would going to be performance hit if I would use non-AHB accesses for ->exec_op().
Not if you implement the dirmap hooks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v13 08/25] kasan: initialize shadow to 0xff for tag-based mode
From: Andrey Konovalov @ 2018-12-10 12:12 UTC (permalink / raw)
To: paul.gortmaker
Cc: Mark Rutland, Kate Stewart, open list:DOCUMENTATION,
Catalin Marinas, Will Deacon, Paul Lawrence,
Linux Memory Management List, Alexander Potapenko, Chintan Pandya,
Christoph Lameter, Ingo Molnar, Jacob Bramley, Ruben Ayrapetyan,
Mark Brand, kasan-dev, linux-sparse, Linux-Next Mailing List,
Geert Uytterhoeven, Linux ARM, Andrey Ryabinin, Dave Martin,
Evgenii Stepanov, Vishwath Mohan, Arnd Bergmann,
Linux Kbuild mailing list, Marc Zyngier, Ramana Radhakrishnan,
Mike Rapoport, Dmitry Vyukov, Kostya Serebryany, Jann Horn,
Ard Biesheuvel, Greg Kroah-Hartman, Nick Desaulniers, LKML,
Eric W . Biederman, Lee Smith, Andrew Morton, Kirill A. Shutemov
In-Reply-To: <CAP=VYLo-o8vpGrpM_+0jdvxLC9uxw+F7_OtsSfRyq24HR1dDwA@mail.gmail.com>
On Mon, Dec 10, 2018 at 2:35 AM Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
>
> On Thu, Dec 6, 2018 at 7:25 AM Andrey Konovalov <andreyknvl@google.com> wrote:
>>
>> A tag-based KASAN shadow memory cell contains a memory tag, that
>> corresponds to the tag in the top byte of the pointer, that points to that
>> memory. The native top byte value of kernel pointers is 0xff, so with
>> tag-based KASAN we need to initialize shadow memory to 0xff.
>>
>> Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>> ---
>> arch/arm64/mm/kasan_init.c | 15 +++++++++++++--
>> include/linux/kasan.h | 8 ++++++++
>
>
> The version of this in linux-next breaks arm64 allmodconfig for me:
>
> mm/kasan/common.c: In function ‘kasan_module_alloc’:
> mm/kasan/common.c:481:17: error: ‘KASAN_SHADOW_INIT’ undeclared (first use in this function)
> __memset(ret, KASAN_SHADOW_INIT, shadow_size);
> ^
> mm/kasan/common.c:481:17: note: each undeclared identifier is reported only once for each function it appears in
> make[3]: *** [mm/kasan/common.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [mm/kasan] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [mm/] Error 2
> make: *** [sub-make] Error 2
Hi Paul,
This is my bad, this should be fixed in v13 of this patchset, which is
in mm right now but not in linux-next yet as it seems.
Thanks!
>
> An automated git bisect-run points at this:
>
> 5c36287813721999e79ac76f637f1ba7e5054402 is the first bad commit
> commit 5c36287813721999e79ac76f637f1ba7e5054402
> Author: Andrey Konovalov <andreyknvl@google.com>
> Date: Wed Dec 5 11:13:21 2018 +1100
>
> kasan: initialize shadow to 0xff for tag-based mode
>
> A quick look at the commit makes me think that the case where the
> "# CONFIG_KASAN_GENERIC is not set" has not been handled.
>
> I'm using an older gcc 4.8.3 - only used for build testing.
>
> Paul.
> --
>
>> mm/kasan/common.c | 3 ++-
>> 3 files changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
>> index 4ebc19422931..7a4a0904cac8 100644
>> --- a/arch/arm64/mm/kasan_init.c
>> +++ b/arch/arm64/mm/kasan_init.c
>> @@ -43,6 +43,15 @@ static phys_addr_t __init kasan_alloc_zeroed_page(int node)
>> return __pa(p);
>> }
>>
>> +static phys_addr_t __init kasan_alloc_raw_page(int node)
>> +{
>> + void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
>> + __pa(MAX_DMA_ADDRESS),
>> + MEMBLOCK_ALLOC_ACCESSIBLE,
>> + node);
>> + return __pa(p);
>> +}
>> +
>> static pte_t *__init kasan_pte_offset(pmd_t *pmdp, unsigned long addr, int node,
>> bool early)
>> {
>> @@ -92,7 +101,9 @@ static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
>> do {
>> phys_addr_t page_phys = early ?
>> __pa_symbol(kasan_early_shadow_page)
>> - : kasan_alloc_zeroed_page(node);
>> + : kasan_alloc_raw_page(node);
>> + if (!early)
>> + memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
>> next = addr + PAGE_SIZE;
>> set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
>> } while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
>> @@ -239,7 +250,7 @@ void __init kasan_init(void)
>> pfn_pte(sym_to_pfn(kasan_early_shadow_page),
>> PAGE_KERNEL_RO));
>>
>> - memset(kasan_early_shadow_page, 0, PAGE_SIZE);
>> + memset(kasan_early_shadow_page, KASAN_SHADOW_INIT, PAGE_SIZE);
>> cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
>>
>> /* At this point kasan is fully initialized. Enable error messages */
>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>> index ec22d548d0d7..c56af24bd3e7 100644
>> --- a/include/linux/kasan.h
>> +++ b/include/linux/kasan.h
>> @@ -153,6 +153,8 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
>>
>> #ifdef CONFIG_KASAN_GENERIC
>>
>> +#define KASAN_SHADOW_INIT 0
>> +
>> void kasan_cache_shrink(struct kmem_cache *cache);
>> void kasan_cache_shutdown(struct kmem_cache *cache);
>>
>> @@ -163,4 +165,10 @@ static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
>>
>> #endif /* CONFIG_KASAN_GENERIC */
>>
>> +#ifdef CONFIG_KASAN_SW_TAGS
>> +
>> +#define KASAN_SHADOW_INIT 0xFF
>> +
>> +#endif /* CONFIG_KASAN_SW_TAGS */
>> +
>> #endif /* LINUX_KASAN_H */
>> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
>> index 5f68c93734ba..7134e75447ff 100644
>> --- a/mm/kasan/common.c
>> +++ b/mm/kasan/common.c
>> @@ -473,11 +473,12 @@ int kasan_module_alloc(void *addr, size_t size)
>>
>> ret = __vmalloc_node_range(shadow_size, 1, shadow_start,
>> shadow_start + shadow_size,
>> - GFP_KERNEL | __GFP_ZERO,
>> + GFP_KERNEL,
>> PAGE_KERNEL, VM_NO_GUARD, NUMA_NO_NODE,
>> __builtin_return_address(0));
>>
>> if (ret) {
>> + __memset(ret, KASAN_SHADOW_INIT, shadow_size);
>> find_vm_area(addr)->flags |= VM_KASAN;
>> kmemleak_ignore(ret);
>> return 0;
>> --
>> 2.20.0.rc1.387.gf8505762e3-goog
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Liang Yang @ 2018-12-10 12:12 UTC (permalink / raw)
To: Boris Brezillon
Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Richard Weinberger, Yixun Lan, linux-kernel,
Marek Vasut, Jian Hu, linux-mtd, Kevin Hilman, Miquel Raynal,
Carlo Caione, linux-amlogic, Brian Norris, David Woodhouse,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <20181210123809.5ade45c4@bbrezillon>
On 2018/12/10 19:38, Boris Brezillon wrote:
> On Mon, 10 Dec 2018 19:23:46 +0800
> Liang Yang <liang.yang@amlogic.com> wrote:
>
>>>> + mtd->ecc_stats.failed++;
>>>> + continue;
>>>> + }
>>>> + mtd->ecc_stats.corrected += ECC_ERR_CNT(*info);
>>>> + bitflips = max_t(u32, bitflips, ECC_ERR_CNT(*info));
>>>> + }
>>>
>>> Are you sure you handle correctly empty pages with bf?
>>>
>> if scramble is enable, i would say yes here.
>> when scramble is disabled, i am considering how to use the helper
>> nand_check_erased_ecc_chunk, but it seems that i can't get the ecc
>> bytes which is caculated by ecc engine.by the way, nfc dma doesn't send
>> out the ecc parity bytes.
>
> Even if the ECC engine is disabled?
>
No.
When ECC engine is disabled, it can read the ecc parity bytes ; but
there is another problem that i need to consider how code struct looks
better when reading error with ecc opened and then try to raw read.
Is there a good idea?
>> so i would suggest using scramble.
>>
>
> No, please don't force people to use the scrambler.
>
>>>> +
>>>> +const void *
>>>> +meson_nand_op_get_dma_safe_output_buf(const struct nand_op_instr *instr)
>>>> +{
>>>> + if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR))
>>>> + return NULL;
>>>> +
>>>> + if (virt_addr_valid(instr->ctx.data.buf.out) &&
>>>> + !object_is_on_stack(instr->ctx.data.buf.out))
>>>
>>> Can you please create helpers for that? I guess it will help removing
>>> these checks once the core will have a DMA-safe approach.
>>>
>> I will use below definition:
>> #define BUFFER_IS_DMA_SAFE(x) \
>> (virt_addr_valid((x)) && (!object_is_on_stack((x))))
>>
>> Is it ok?
>
> Please define a function, not a macro.
> ok
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: shmobile: Fix R-Car Gen2 regulator quirk
From: Simon Horman @ 2018-12-10 12:08 UTC (permalink / raw)
To: Marek Vasut
Cc: Geert Uytterhoeven, Kuninori Morimoto, Yoshihiro Shimoda,
linux-renesas-soc, Wolfram Sang, linux-arm-kernel, Marek Vasut
In-Reply-To: <20181207202858.17129-1-marek.vasut+renesas@gmail.com>
On Fri, Dec 07, 2018 at 09:28:58PM +0100, Marek Vasut wrote:
> The quirk code currently detects all compatible I2C chips with a shared
> IRQ line on all I2C busses, adds them into a list, and registers a bus
> notifier. For every chip for which the bus notifier triggers, the quirk
> code performs I2C transfer on that I2C bus for all addresses in the list.
> The problem is that this may generate transfers to non-existing chips on
> systems with multiple I2C busses.
>
> This patch adds a check to verify that the I2C bus to which the chip with
> shared IRQ is attached to matches the I2C bus of the chip which triggered
> the bus notifier and only starts the I2C transfer if they match.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: linux-renesas-soc@vger.kernel.org
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> index d4774d8ff997..f78e5348bd4c 100644
> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> @@ -40,6 +40,7 @@
> struct regulator_quirk {
> struct list_head list;
> const struct of_device_id *id;
> + struct device_node *np;
> struct of_phandle_args irq_args;
> struct i2c_msg i2c_msg;
> bool shared; /* IRQ line is shared */
> @@ -102,6 +103,9 @@ static int regulator_quirk_notify(struct notifier_block *nb,
> if (!pos->shared)
> continue;
>
> + if (pos->np->parent != client->dev.parent->of_node)
> + continue;
> +
> dev_info(&client->dev, "clearing %s@0x%02x interrupts\n",
> pos->id->compatible, pos->i2c_msg.addr);
>
> @@ -167,6 +171,7 @@ static int __init rcar_gen2_regulator_quirk(void)
> memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
>
> quirk->id = id;
> + quirk->np = np;
> quirk->i2c_msg.addr = addr;
>
> ret = of_irq_parse_one(np, 0, argsa);
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Nishanth Menon @ 2018-12-10 12:06 UTC (permalink / raw)
To: Sekhar Nori
Cc: mark.rutland, devicetree, ulf.hansson, Arnd Bergmann,
Tony Lindgren, linux-kernel, robh+dt, kishon, t-kristo,
Faiz Abbas, adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <c1dd9783-84dc-9dad-ea94-9a14a4ad814d@ti.com>
On 13:33-20181210, Sekhar Nori wrote:
> On 08/12/18 9:24 PM, Nishanth Menon wrote:
> > On 14:12-20181207, Faiz Abbas wrote:
> >
> >> +
> >> +&sdhci0 {
> >> + status = "okay";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&main_mmc0_pins_default>;
> >> + bus-width = <8>;
> >> + non-removable;
> >> + ti,driver-strength-ohm = <50>;
> >
> > ^^
> >
> >> +};
> >> +
> >> +&sdhci1 {
> >> + status = "okay";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&main_mmc1_pins_default>;
> >> + ti,driver-strength-ohm = <50>;
> >
> > NAK.
> >
> > $ git checkout next-20181207
> > $ git grep ti,driver-strength-ohm Documentation
> > $
> >
> > Nada.. And.. I think "new phy binding" probably introduces this.
> > [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185
> >
> > If your patches are'nt really ready, please send them as RFC, I am not
> > really in a mood to track the status of every single driver subsystem.
> >
> > If your binding is not in linux next at the baremin, as far as I am
> > concerned, this is not ready, and should be RFC.
>
> No, RFC does not say "do not merge" or "this has dependencies". RFC is
> used to invite a stronger review when introducing a new concept. Its
> fair game to apply patches marked RFC if maintainer is okay with the
> content.
True, fair enough.. RFC is request for comments. Anyways, that is
besides the point.
>
> Dependencies are either noted in cover-letter or below the patch
> tear-line. With what you are asking, looks like patches need to be
> resubmitted once dependencies are cleared, even if there is no change in
> the content itself. This will be additional work.
Yes please. There would be other dts changes that are probably ready and
I really wont be tracking everything happening on other drivers. If the
binding is present at least in next, it is a good indication of things
clean and ready to go.
>
> That said, if it makes life convenient for you, you can impose such a
> rule for patches you need to handle. But I think it will take some
> getting used for developers who send patches to you as I don't think
> this is a norm elsewhere.
>
> Adding Tony and Arnd as well, in case I have missed some recently
> accepted convention.
I have'nt looked at any conventions, The style I prefer to follow when I do
submissions: It is my job to get the bindings in, until then my actual
dts is just "request for comments". Only after the bindings are merged
do I formally submit dts - simply because I dont expect dts maintainer
to track what happened to my driver's binding and discussions there of.
Seriously, is'nt it really reasonable for dts maintainer to check every
single driver's development status in 15 different mailing lists?
Because, it sounds like what you are asking. At least I wont have time
for it..
I really am curious how Arnd / Tony actually pull this one off.. If they
have continous cron job for checking if your patch is ready... I doubt
it..
--
Regards,
Nishanth Menon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] ARM: defconfig: Switch LPC32xx to use PL11x DRM driver
From: Linus Walleij @ 2018-12-10 12:04 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: Linus Walleij, linux-arm-kernel
In-Reply-To: <20181210120454.9099-1-linus.walleij@linaro.org>
None of the LPC32xx device trees contains any display settings,
it just defines a device tree node for the CLCD (PL11x) left
as "disabled" on lpc3250-ea3250 and "okay" on lpc3250-phy3250
but no panels are attached on any device tree, so the driver
will simply bail out.
I conclude that the hardware is dormant on existing
systems, so we can without any problems switch the defconfig
over from the old ARMCLCD frame buffer driver to the new
PL11x DRM driver.
Cc: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/lpc32xx_defconfig | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 120d6b18df9a..6273d90c420a 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -111,10 +111,12 @@ CONFIG_SENSORS_DS620=y
CONFIG_SENSORS_MAX6639=y
CONFIG_WATCHDOG=y
CONFIG_PNX4008_WATCHDOG=y
-CONFIG_FB=y
-CONFIG_FB_ARMCLCD=y
+CONFIG_DRM=y
+CONFIG_DRM_PL111=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox