* Re: [PATCH 2/3] dt-bindings: pinctrl: rockchip: update example
From: Linus Walleij @ 2020-05-18 7:20 UTC (permalink / raw)
To: Johan Jonker
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heiko Stübner, open list:ARM/Rockchip SoC...,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
Rob Herring, Linux ARM
In-Reply-To: <20200512203524.7317-2-jbx6244@gmail.com>
On Tue, May 12, 2020 at 10:35 PM Johan Jonker <jbx6244@gmail.com> wrote:
> The Rockchip dtsi and dts files have been bulk-converted for the
> remaining raw gpio numbers into their descriptive counterparts and
> also got rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
> mappings, so update the example as well.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
This patch applied to the pinctrl tree.
Yours,
Linus Walleij
_______________________________________________
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 1/2] dt-bindings: serial: Document CTS/RTS gpios in STM32 UART
From: Geert Uytterhoeven @ 2020-05-18 7:04 UTC (permalink / raw)
To: mani
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Torgue, Greg KH, Linux Kernel Mailing List,
Andy Shevchenko, Rob Herring, Maxime Coquelin,
open list:SERIAL DRIVERS, fabrice.gasnier, linux-stm32, Linux ARM
In-Reply-To: <20200420170204.24541-2-mani@kernel.org>
Hi Mani,
On Mon, Apr 20, 2020 at 7:02 PM <mani@kernel.org> wrote:
> From: Manivannan Sadhasivam <mani@kernel.org>
>
> Document the use of CTS/RTS gpios for flow control in STM32 UART
> controller. These properties can be used instead of 'st,hw-flow-ctrl'
> for making use of any gpio pins for flow control instead of dedicated
> pins. It should be noted that both CTS/RTS and 'st,hw-flow-ctrl'
> properties cannot co-exist in a design.
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> @@ -55,6 +61,14 @@ properties:
> linux,rs485-enabled-at-boot-time: true
> rs485-rx-during-tx: true
>
> +if:
> + required:
> + - st,hw-flow-ctrl
Perhaps "st,hw-flow-ctrl" should be deprecated, in favor of the standard
"uart-has-rtscts" property?
Of course the driver needs to gain support for the latter first.
> +then:
> + properties:
> + cts-gpios: false
> + rts-gpios: false
> +
> required:
> - compatible
> - reg
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/4] kasan: record and print the free track
From: Walter Wu @ 2020-05-18 6:27 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Move free track from slub alloc meta-data to slub free meta-data in
order to make struct kasan_free_meta size is 16 bytes. It is a good
size because it is the minimal redzone size and a good number of
alignment.
For free track in generic KASAN, we do the modification in struct
kasan_alloc_meta and kasan_free_meta:
- remove free track from kasan_alloc_meta.
- add free track into kasan_free_meta.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
---
mm/kasan/common.c | 33 ++++++++++-----------------------
mm/kasan/generic.c | 18 ++++++++++++++++++
mm/kasan/kasan.h | 7 +++++++
mm/kasan/report.c | 20 --------------------
mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
5 files changed, 72 insertions(+), 43 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 8bc618289bb1..6500bc2bb70c 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
return stack_depot_save(entries, nr_entries, flags);
}
-static inline void set_track(struct kasan_track *track, gfp_t flags)
+void kasan_set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
track->stack = kasan_save_stack(flags);
@@ -249,9 +249,7 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size,
*size += sizeof(struct kasan_alloc_meta);
/* Add free meta. */
- if (IS_ENABLED(CONFIG_KASAN_GENERIC) &&
- (cache->flags & SLAB_TYPESAFE_BY_RCU || cache->ctor ||
- cache->object_size < sizeof(struct kasan_free_meta))) {
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
cache->kasan_info.free_meta_offset = *size;
*size += sizeof(struct kasan_free_meta);
}
@@ -299,24 +297,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
return (void *)object + cache->kasan_info.free_meta_offset;
}
-
-static void kasan_set_free_info(struct kmem_cache *cache,
- void *object, u8 tag)
-{
- struct kasan_alloc_meta *alloc_meta;
- u8 idx = 0;
-
- alloc_meta = get_alloc_info(cache, object);
-
-#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
- idx = alloc_meta->free_track_idx;
- alloc_meta->free_pointer_tag[idx] = tag;
- alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
-#endif
-
- set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
-}
-
void kasan_poison_slab(struct page *page)
{
unsigned long i;
@@ -396,6 +376,13 @@ void * __must_check kasan_init_slab_obj(struct kmem_cache *cache,
alloc_info = get_alloc_info(cache, object);
__memset(alloc_info, 0, sizeof(*alloc_info));
+ if (IS_ENABLED(CONFIG_KASAN_GENERIC)) {
+ struct kasan_free_meta *free_info;
+
+ free_info = get_free_info(cache, object);
+ __memset(free_info, 0, sizeof(*free_info));
+ }
+
if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
object = set_tag(object,
assign_tag(cache, object, true, false));
@@ -492,7 +479,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
KASAN_KMALLOC_REDZONE);
if (cache->flags & SLAB_KASAN)
- set_track(&get_alloc_info(cache, object)->alloc_track, flags);
+ kasan_set_track(&get_alloc_info(cache, object)->alloc_track, flags);
return set_tag(object, tag);
}
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 78d8e0a75a8a..988bc095b738 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -345,3 +345,21 @@ void kasan_record_aux_stack(void *addr)
alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0];
alloc_info->rcu_stack[0] = kasan_save_stack(GFP_NOWAIT);
}
+
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_free_meta *free_meta;
+
+ free_meta = get_free_info(cache, object);
+ kasan_set_track(&free_meta->free_track, GFP_NOWAIT);
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_free_meta *free_meta;
+
+ free_meta = get_free_info(cache, object);
+ return &free_meta->free_track;
+}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 870c5dd07756..87ee3626b8b0 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -127,6 +127,9 @@ struct kasan_free_meta {
* Otherwise it might be used for the allocator freelist.
*/
struct qlist_node quarantine_link;
+#ifdef CONFIG_KASAN_GENERIC
+ struct kasan_track free_track;
+#endif
};
struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
@@ -168,6 +171,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
struct page *kasan_addr_to_page(const void *addr);
depot_stack_handle_t kasan_save_stack(gfp_t flags);
+void kasan_set_track(struct kasan_track *track, gfp_t flags);
+void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag);
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 5ee66cf7e27c..7e9f9f6d5e85 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -159,26 +159,6 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
(void *)(object_addr + cache->object_size));
}
-static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
- void *object, u8 tag)
-{
- struct kasan_alloc_meta *alloc_meta;
- int i = 0;
-
- alloc_meta = get_alloc_info(cache, object);
-
-#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
- for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
- if (alloc_meta->free_pointer_tag[i] == tag)
- break;
- }
- if (i == KASAN_NR_FREE_STACKS)
- i = alloc_meta->free_track_idx;
-#endif
-
- return &alloc_meta->free_track[i];
-}
-
#ifdef CONFIG_KASAN_GENERIC
static void print_stack(depot_stack_handle_t stack)
{
diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
index 25b7734e7013..201dee5d6ae0 100644
--- a/mm/kasan/tags.c
+++ b/mm/kasan/tags.c
@@ -162,3 +162,40 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
kasan_poison_shadow((void *)addr, size, tag);
}
EXPORT_SYMBOL(__hwasan_tag_memory);
+
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ u8 idx = 0;
+
+ alloc_meta = get_alloc_info(cache, object);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ idx = alloc_meta->free_track_idx;
+ alloc_meta->free_pointer_tag[idx] = tag;
+ alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
+#endif
+
+ kasan_set_track(&alloc_meta->free_track[idx], GFP_NOWAIT);
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ int i = 0;
+
+ alloc_meta = get_alloc_info(cache, object);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ for (i = 0; i < KASAN_NR_FREE_STACKS; i++) {
+ if (alloc_meta->free_pointer_tag[i] == tag)
+ break;
+ }
+ if (i == KASAN_NR_FREE_STACKS)
+ i = alloc_meta->free_track_idx;
+#endif
+
+ return &alloc_meta->free_track[i];
+}
--
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 related
* [PATCH v3 3/4] kasan: add tests for call_rcu stack recording
From: Walter Wu @ 2020-05-18 6:30 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Test call_rcu() call stack recording whether it correctly is printed
in KASAN report.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
lib/test_kasan.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..0e9ff02f0a8b 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -792,6 +792,35 @@ static noinline void __init vmalloc_oob(void)
static void __init vmalloc_oob(void) {}
#endif
+static struct kasan_rcu_info {
+ int i;
+ struct rcu_head rcu;
+} *global_ptr;
+
+static noinline void __init kasan_rcu_reclaim(struct rcu_head *rp)
+{
+ struct kasan_rcu_info *fp = container_of(rp,
+ struct kasan_rcu_info, rcu);
+
+ kfree(fp);
+ fp->i = 1;
+}
+
+static noinline void __init kasan_rcu_uaf(void)
+{
+ struct kasan_rcu_info *ptr;
+
+ pr_info("use-after-free in kasan_rcu_reclaim\n");
+ ptr = kmalloc(sizeof(struct kasan_rcu_info), GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ global_ptr = rcu_dereference_protected(ptr, NULL);
+ call_rcu(&global_ptr->rcu, kasan_rcu_reclaim);
+}
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -839,6 +868,7 @@ static int __init kmalloc_tests_init(void)
kasan_bitops();
kmalloc_double_kzfree();
vmalloc_oob();
+ kasan_rcu_uaf();
kasan_restore_multi_shot(multishot);
--
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 related
* [PATCH v3 0/4] kasan: memorize and print call_rcu stack
From: Walter Wu @ 2020-05-18 6:24 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Paul E . McKenney, Josh Triplett,
Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Andrew Morton
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
This patchset improves KASAN reports by making them to have
call_rcu() call stack information. It is useful for programmers
to solve use-after-free or double-free memory issue.
The KASAN report was as follows(cleaned up slightly):
BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60
Freed by task 0:
kasan_save_stack+0x24/0x50
kasan_set_track+0x24/0x38
kasan_set_free_info+0x18/0x20
__kasan_slab_free+0x10c/0x170
kasan_slab_free+0x10/0x18
kfree+0x98/0x270
kasan_rcu_reclaim+0x1c/0x60
Last one call_rcu() call stack:
kasan_save_stack+0x24/0x50
kasan_record_aux_stack+0xbc/0xd0
call_rcu+0x8c/0x580
kasan_rcu_uaf+0xf4/0xf8
Generic KASAN will record the last two call_rcu() call stacks and
print up to 2 call_rcu() call stacks in KASAN report. it is only
suitable for generic KASAN.
This feature considers the size of struct kasan_alloc_meta and
kasan_free_meta, we try to optimize the structure layout and size
, let it get better memory consumption.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
[2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
Changes since v2:
- remove new config option, default enable it in generic KASAN
- test this feature in SLAB/SLUB, it is pass.
- modify macro to be more clearly
- modify documentation
Changes since v3:
- change recording from first/last to the last two call stacks
- move free track into kasan free meta
- init slab_free_meta on object slot creation
- modify documentation
Walter Wu (4):
rcu/kasan: record and print call_rcu() call stack
kasan: record and print the free track
kasan: add tests for call_rcu stack recording
kasan: update documentation for generic kasan
Documentation/dev-tools/kasan.rst | 3 +++
include/linux/kasan.h | 2 ++
kernel/rcu/tree.c | 2 ++
lib/Kconfig.kasan | 2 ++
lib/test_kasan.c | 30 ++++++++++++++++++++++++++++++
mm/kasan/common.c | 37 ++++++++++++-------------------------
mm/kasan/generic.c | 38 ++++++++++++++++++++++++++++++++++++++
mm/kasan/kasan.h | 17 +++++++++++++++++
mm/kasan/report.c | 36 ++++++++++++++++++++----------------
mm/kasan/tags.c | 37 +++++++++++++++++++++++++++++++++++++
10 files changed, 163 insertions(+), 41 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 4/4] kasan: update documentation for generic kasan
From: Walter Wu @ 2020-05-18 6:31 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Jonathan Corbet
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Generic KASAN will support to record the last two call_rcu() call
stacks and print them in KASAN report. so we update documentation.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
---
Documentation/dev-tools/kasan.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index c652d740735d..fede42e6536b 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -193,6 +193,9 @@ function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
+Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one
+and the second to last.
+
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
--
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 related
* [PATCH v3 1/4] rcu/kasan: record and print call_rcu() call stack
From: Walter Wu @ 2020-05-18 6:26 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Paul E . McKenney, Josh Triplett,
Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Andrew Morton
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
This feature will record the last two call_rcu() call stack and
prints up to 2 call_rcu() call stacks in KASAN report.
When call_rcu() is called, we store the call_rcu() call stack into
slub alloc meta-data, so that the KASAN report can print rcu stack.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
[2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
---
include/linux/kasan.h | 2 ++
kernel/rcu/tree.c | 2 ++
lib/Kconfig.kasan | 2 ++
mm/kasan/common.c | 4 ++--
mm/kasan/generic.c | 20 ++++++++++++++++++++
mm/kasan/kasan.h | 10 ++++++++++
mm/kasan/report.c | 24 ++++++++++++++++++++++++
7 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 31314ca7c635..23b7ee00572d 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
void kasan_cache_shrink(struct kmem_cache *cache);
void kasan_cache_shutdown(struct kmem_cache *cache);
+void kasan_record_aux_stack(void *ptr);
#else /* CONFIG_KASAN_GENERIC */
static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
+static inline void kasan_record_aux_stack(void *ptr) {}
#endif /* CONFIG_KASAN_GENERIC */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 06548e2ebb72..36a4ff7f320b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -57,6 +57,7 @@
#include <linux/slab.h>
#include <linux/sched/isolation.h>
#include <linux/sched/clock.h>
+#include <linux/kasan.h>
#include "../time/tick-internal.h"
#include "tree.h"
@@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
head->func = func;
head->next = NULL;
local_irq_save(flags);
+ kasan_record_aux_stack(head);
rdp = this_cpu_ptr(&rcu_data);
/* Add the callback to our list. */
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..4e83cf6e3caa 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -58,6 +58,8 @@ config KASAN_GENERIC
For better error detection enable CONFIG_STACKTRACE.
Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
(the resulting kernel does not boot).
+ In generic mode KASAN prints the last two call_rcu() call stacks in
+ reports.
config KASAN_SW_TAGS
bool "Software tag-based mode"
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2906358e42f0..8bc618289bb1 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -41,7 +41,7 @@
#include "kasan.h"
#include "../slab.h"
-static inline depot_stack_handle_t save_stack(gfp_t flags)
+depot_stack_handle_t kasan_save_stack(gfp_t flags)
{
unsigned long entries[KASAN_STACK_DEPTH];
unsigned int nr_entries;
@@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
static inline void set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
- track->stack = save_stack(flags);
+ track->stack = kasan_save_stack(flags);
}
void kasan_enable_current(void)
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 56ff8885fe2e..78d8e0a75a8a 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -325,3 +325,23 @@ DEFINE_ASAN_SET_SHADOW(f2);
DEFINE_ASAN_SET_SHADOW(f3);
DEFINE_ASAN_SET_SHADOW(f5);
DEFINE_ASAN_SET_SHADOW(f8);
+
+void kasan_record_aux_stack(void *addr)
+{
+ struct page *page = kasan_addr_to_page(addr);
+ struct kmem_cache *cache;
+ struct kasan_alloc_meta *alloc_info;
+ void *object;
+
+ if (!(page && PageSlab(page)))
+ return;
+
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_info = get_alloc_info(cache, object);
+
+ /* record last two call_rcu() call stacks */
+ if (alloc_info->rcu_stack[0])
+ alloc_info->rcu_stack[1] = alloc_info->rcu_stack[0];
+ alloc_info->rcu_stack[0] = kasan_save_stack(GFP_NOWAIT);
+}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index e8f37199d885..870c5dd07756 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -104,7 +104,15 @@ struct kasan_track {
struct kasan_alloc_meta {
struct kasan_track alloc_track;
+#ifdef CONFIG_KASAN_GENERIC
+ /*
+ * call_rcu() call stack is stored into struct kasan_alloc_meta.
+ * The free stack is stored into struct kasan_free_meta.
+ */
+ depot_stack_handle_t rcu_stack[2];
+#else
struct kasan_track free_track[KASAN_NR_FREE_STACKS];
+#endif
#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
u8 free_track_idx;
@@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
struct page *kasan_addr_to_page(const void *addr);
+depot_stack_handle_t kasan_save_stack(gfp_t flags);
+
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 80f23c9da6b0..5ee66cf7e27c 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -179,6 +179,17 @@ static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
return &alloc_meta->free_track[i];
}
+#ifdef CONFIG_KASAN_GENERIC
+static void print_stack(depot_stack_handle_t stack)
+{
+ unsigned long *entries;
+ unsigned int nr_entries;
+
+ nr_entries = stack_depot_fetch(stack, &entries);
+ stack_trace_print(entries, nr_entries, 0);
+}
+#endif
+
static void describe_object(struct kmem_cache *cache, void *object,
const void *addr, u8 tag)
{
@@ -192,6 +203,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
free_track = kasan_get_free_track(cache, object, tag);
print_track(free_track, "Freed");
pr_err("\n");
+
+#ifdef CONFIG_KASAN_GENERIC
+ if (alloc_info->rcu_stack[0]) {
+ pr_err("Last one call_rcu() call stack:\n");
+ print_stack(alloc_info->rcu_stack[0]);
+ pr_err("\n");
+ }
+ if (alloc_info->rcu_stack[1]) {
+ pr_err("Second to last call_rcu() call stack:\n");
+ print_stack(alloc_info->rcu_stack[1]);
+ pr_err("\n");
+ }
+#endif
}
describe_object_addr(cache, object, addr);
--
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 related
* Re: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
From: Lecopzer Chen @ 2020-05-18 6:26 UTC (permalink / raw)
To: Sumit Garg
Cc: Mark Rutland, Jian-Lin Chen, Will Deacon, alexander.shishkin,
Catalin Marinas, yj.chiang, Linux Kernel Mailing List, acme,
Peter Zijlstra, mingo, linux-mediatek, linux-arm-kernel,
matthias.bgg, namhyung, jolsa, julien.thierry.kdev
In-Reply-To: <CAFA6WYNwp+_ENiS8QDao5+RXyt5ofJZyq6c5CKG_d0CNEmBNYg@mail.gmail.com>
HI Sumit,
Thanks for your information.
I've already implemented IPI (same as you did [1], little difference
in detail), hardlockup detector and perf in last year(2019) for
debuggability.
And now we tend to upstream to reduce kernel maintaining effort.
I'm glad if someone in ARM can do this work :)
Hi Julien,
Does any Arm maintainers can proceed this action?
This is really useful in debugging.
Thank you!!
[1] https://lkml.org/lkml/2020/4/24/328
Lecopzer
Sumit Garg <sumit.garg@linaro.org> 於 2020年5月18日 週一 下午1:46寫道：
>
> + Julien
>
> Hi Lecopzer,
>
> On Sat, 16 May 2020 at 18:20, Lecopzer Chen <lecopzer@gmail.com> wrote:
> >
> > These series implement Perf NMI funxtionality and depends on
> > Pseudo NMI [1] which has been upstreamed.
> >
> > In arm64 with GICv3, Pseudo NMI was implemented for NMI-like interruts.
> > That can be extended to Perf NMI which is the prerequisite for hard-lockup
> > detector which had already a standard interface inside Linux.
> >
> > Thus the first step we need to implement perf NMI interface and make sure
> > it works fine.
> >
>
> This is something that is already implemented via Julien's patch-set
> [1]. Its v4 has been floating since July, 2019 and I couldn't find any
> major blocking comments but not sure why things haven't progressed
> further.
>
> Maybe Julien or Arm maintainers can provide updates on existing
> patch-set [1] and how we should proceed further with this interesting
> feature.
>
> And regarding hard-lockup detection, I have been able to enable it
> based on perf NMI events using Julien's perf patch-set [1]. Have a
> look at the patch here [2].
>
> [1] https://patchwork.kernel.org/cover/11047407/
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
>
> -Sumit
>
> > Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the link [2]
> > did.
> >
> > [1] https://lkml.org/lkml/2019/1/31/535
> > [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq
> >
> >
> > Lecopzer Chen (3):
> > arm_pmu: Add support for perf NMI interrupts registration
> > arm64: perf: Support NMI context for perf event ISR
> > arm64: Kconfig: Add support for the Perf NMI
> >
> > arch/arm64/Kconfig | 10 +++++++
> > arch/arm64/kernel/perf_event.c | 36 ++++++++++++++++++------
> > drivers/perf/arm_pmu.c | 51 ++++++++++++++++++++++++++++++----
> > include/linux/perf/arm_pmu.h | 6 ++++
> > 4 files changed, 88 insertions(+), 15 deletions(-)
> >
> > --
> > 2.25.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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 v1 8/9] arm64: dts: actions: Add MMC controller support for S700
From: Manivannan Sadhasivam @ 2020-05-18 6:17 UTC (permalink / raw)
To: Amit Tomer
Cc: devicetree, André Przywara, linux-actions,
cristian.ciocaltea, Rob Herring, Andreas Färber,
linux-arm-kernel
In-Reply-To: <CABHD4K-MHs4jhL_9otJJ_xjC1uv1N20mnHqT39b2kob7WjZcVQ@mail.gmail.com>
On 0518, Amit Tomer wrote:
> Hi,
>
> > I recommend reading the DT spec, chapter 2.3.1 "compatible":
> > https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf
>
> My point is more about, DT validation is not happy about this situation.
> For instance when I run dt-validate, do see following:
>
> /home/amit/work/kernel_work/linux/arch/arm64/boot/dts/actions/s700-cubieboard7.dt.yaml:
> mmc@e0210000: compatible: Additional items are not allowed
> ('actions,s700-mmc' was unexpected)
>
> and I am not sure if this is because DT and driver has different
> number of compatible strings.
>
Yeah, the DT YAML validation tool doesn't allow this. And there were patches
removing the additional compatible from DTS.
I don't know if the DT fallback is discouraged or not.
Anyway, is enough investigation done to justify that we need SoC specific tweaks
in the driver? I think I did look into the downstream code for s700/s500 while
upstreaming this driver and convinced myself that the same driver could be
reused without modifications.
Thanks,
Mani
> Thanks
> Amit
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mmc: host: meson-mx-sdhc: fix building with CONFIG_MMC_MESON_MX_SDHC=m
From: Martin Blumenstingl @ 2020-05-18 6:08 UTC (permalink / raw)
To: ulf.hansson, linux-mmc, linux-amlogic
Cc: Martin Blumenstingl, Stephen Rothwell, linux-kernel,
linux-arm-kernel
For an x86_64 allmodconfig build Stephen reports that building
meson-mx-sdhc-clkc.o warns that MODULE_LICENSE is missing and when
linking meson_mx_sdhc_register_clkc cannot be found.
Compile the MMC controller driver together with the build-in clock
controller driver into one module rather than using two separate
modules to fix these issues.
Fixes: 53ded1b676d199 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/mmc/host/Makefile | 3 ++-
drivers/mmc/host/{meson-mx-sdhc.c => meson-mx-sdhc-mmc.c} | 0
2 files changed, 2 insertions(+), 1 deletion(-)
rename drivers/mmc/host/{meson-mx-sdhc.c => meson-mx-sdhc-mmc.c} (100%)
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 8bcb420e071c..8f459259181e 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -68,7 +68,8 @@ obj-$(CONFIG_MMC_VUB300) += vub300.o
obj-$(CONFIG_MMC_USHC) += ushc.o
obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
obj-$(CONFIG_MMC_MESON_GX) += meson-gx-mmc.o
-obj-$(CONFIG_MMC_MESON_MX_SDHC) += meson-mx-sdhc-clkc.o meson-mx-sdhc.o
+meson-mx-sdhc-objs := meson-mx-sdhc-clkc.o meson-mx-sdhc-mmc.o
+obj-$(CONFIG_MMC_MESON_MX_SDHC) += meson-mx-sdhc.o
obj-$(CONFIG_MMC_MESON_MX_SDIO) += meson-mx-sdio.o
obj-$(CONFIG_MMC_MOXART) += moxart-mmc.o
obj-$(CONFIG_MMC_SUNXI) += sunxi-mmc.o
diff --git a/drivers/mmc/host/meson-mx-sdhc.c b/drivers/mmc/host/meson-mx-sdhc-mmc.c
similarity index 100%
rename from drivers/mmc/host/meson-mx-sdhc.c
rename to drivers/mmc/host/meson-mx-sdhc-mmc.c
--
2.26.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
* RE: [PATCH] ARM: dts: imx7d-pinfunc: add input mux for ENET2 mdio
From: Aisheng Dong @ 2020-05-18 6:08 UTC (permalink / raw)
To: Andy Duan, Steffen Trumtrar, Shawn Guo
Cc: linux-arm-kernel@lists.infradead.org, Rob Herring, Fabio Estevam,
dl-linux-imx, Pengutronix Kernel Team
In-Reply-To: <AM6PR0402MB3607E70A60E62656D1898424FFB80@AM6PR0402MB3607.eurprd04.prod.outlook.com>
> From: Andy Duan <fugang.duan@nxp.com>
> Sent: Monday, May 18, 2020 12:36 PM
>
> From: Aisheng Dong <aisheng.dong@nxp.com> Sent: Monday, May 18, 2020
> 11:55 AM
> > > From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > Sent: Friday, May 15, 2020 7:42 PM
> > >
> > > Add the missing input mux for ENET2 mdio. Without this setting, it
> > > is not possible to read the MDIO answers back from the PHY.
> > >
> > > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > ---
> > > arch/arm/boot/dts/imx7d-pinfunc.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h
> > > b/arch/arm/boot/dts/imx7d-pinfunc.h
> > > index 08ca1608fdb1..69f2c1ec8254 100644
> > > --- a/arch/arm/boot/dts/imx7d-pinfunc.h
> > > +++ b/arch/arm/boot/dts/imx7d-pinfunc.h
> > > @@ -592,7 +592,7 @@
> > > #define MX7D_PAD_UART2_RX_DATA__ECSPI1_SS3
> > > 0x0130 0x03A0 0x0000 0x3 0x0
> > > #define MX7D_PAD_UART2_RX_DATA__ENET2_1588_EVENT1_IN
> > > 0x0130 0x03A0 0x0000 0x4 0x0
> > > #define MX7D_PAD_UART2_RX_DATA__GPIO4_IO2
> > > 0x0130 0x03A0 0x0000 0x5 0x0
> > > -#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> > > 0x0130 0x03A0 0x0000 0x6 0x0
> > > +#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> > > 0x0130 0x03A0 0x0574 0x6 0x1
> >
> > It's strange that I didn't find this select input setting from latest RM.
> > Anything I missed?
> >
> > Also copy Andy to comment.
> >
> Check the RM in my local, it define the signal select input from UART2_RX_DATA,
> it is correct with the change.
>
> Aisheng, we can check together for our RM version.
You're right. I checked the wrong place.
So for this patch:
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
> > Regards
> > Aisheng
> >
> > > #define MX7D_PAD_UART2_TX_DATA__UART2_DCE_TX
> > > 0x0134 0x03A4 0x0000 0x0 0x0
> > > #define MX7D_PAD_UART2_TX_DATA__UART2_DTE_RX
> > > 0x0134 0x03A4 0x06FC 0x0 0x3
> > > #define MX7D_PAD_UART2_TX_DATA__I2C2_SDA
> > > 0x0134 0x03A4 0x05E0 0x1 0x0
> > > --
> > > 2.26.2
_______________________________________________
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] dt-bindings: pwm: Convert mxs pwm to json-schema
From: Aisheng Dong @ 2020-05-18 6:07 UTC (permalink / raw)
To: Anson Huang, thierry.reding@gmail.com,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB3916B5980C0681BFF3C08FE5F5B80@DB3PR0402MB3916.eurprd04.prod.outlook.com>
> From: Anson Huang <anson.huang@nxp.com>
> Sent: Monday, May 18, 2020 1:32 PM
>
> > Subject: RE: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema
> >
> > > +title: Freescale MXS PWM controller
> > > +
> > > +maintainers:
> > > + - Shawn Guo <shawn.guo@linaro.org>
> > > + - Anson Huang <anson.huang@nxp.com>
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - fsl,imx23-pwm
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + "#pwm-cells":
> > > + const: 3
> >
> > Seems you missed the reference to pwm.yaml.
>
> It is because many pwm yaml files also has no "#pwm-cells" reference, so I am
> NOT sure if it is a MUST:
>
> Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
> Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
> ...
I guess we'd better add it.
Let's wait for Rob's feedback.
Regards
Aisheng
>
> Anson
_______________________________________________
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] dt-bindings: pwm: Convert imx tpm pwm to json-schema
From: Aisheng Dong @ 2020-05-18 6:00 UTC (permalink / raw)
To: Anson Huang, thierry.reding@gmail.com,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, p.zabel@pengutronix.de,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589439259-28510-2-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Thursday, May 14, 2020 2:54 PM
>
> Convert the imx tpm pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/pwm/imx-tpm-pwm.txt | 22 ---------
> .../devicetree/bindings/pwm/imx-tpm-pwm.yaml | 55
> ++++++++++++++++++++++
> 2 files changed, 55 insertions(+), 22 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
> create mode 100644
> Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
> b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
> deleted file mode 100644
> index 5bf2095..0000000
> --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -Freescale i.MX TPM PWM controller
> -
> -Required properties:
> -- compatible : Should be "fsl,imx7ulp-pwm".
> -- reg: Physical base address and length of the controller's registers.
> -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
> the cells format.
> -- clocks : The clock provided by the SoC to drive the PWM.
> -- interrupts: The interrupt for the PWM controller.
> -
> -Note: The TPM counter and period counter are shared between multiple
> channels, so all channels -should use same period setting.
> -
> -Example:
> -
> -tpm4: pwm@40250000 {
> - compatible = "fsl,imx7ulp-pwm";
> - reg = <0x40250000 0x1000>;
> - assigned-clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>;
> - assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>;
> - clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>;
> - #pwm-cells = <3>;
> -};
> diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
> b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
> new file mode 100644
> index 0000000..fe9ef42
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fschemas%2Fpwm%2Fimx-tpm-pwm.yaml%23&data=02%7C
> 01%7Caishe
> +ng.dong%40nxp.com%7C8dba0c8c150b4885913008d7f7d5320d%7C686ea
> 1d3bc2b4c6f
> +a92cd99c5c301635%7C0%7C0%7C637250367345109522&sdata=WT6
> kA9lpZMBYgS7
> +whY9rlVq5qDcGZYheOHoTR8nupOY%3D&reserved=0
> +$schema:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Caishen
> g.dong%
> +40nxp.com%7C8dba0c8c150b4885913008d7f7d5320d%7C686ea1d3bc2b4c
> 6fa92cd99c
> +5c301635%7C0%7C0%7C637250367345109522&sdata=AlzT4bC3GZgV
> cDJn5svMqjt
> +5HN7Lj60Fc7m%2B3D0g0xQ%3D&reserved=0
> +
> +title: Freescale i.MX TPM PWM controller
> +
> +maintainers:
> + - Anson Huang <anson.huang@nxp.com>
> +
> +description: |
> + The TPM counter and period counter are shared between multiple
> + channels, so all channels should use same period setting.
> +
> +properties:
> + "#pwm-cells":
> + const: 3
> +
Same issue, missing the reference to pwm.yaml?
> + compatible:
> + enum:
> + - fsl,imx7ulp-pwm
> +
> + reg:
> + maxItems: 1
> +
> + assigned-clocks:
> + maxItems: 1
> +
> + assigned-clock-parents:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> +required:
> + - "#pwm-cells"
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx7ulp-clock.h>
> +
> + pwm@40250000 {
> + compatible = "fsl,imx7ulp-pwm";
> + reg = <0x40250000 0x1000>;
> + assigned-clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>;
> + assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>;
> + clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>;
> + #pwm-cells = <3>;
> + };
> --
> 2.7.4
_______________________________________________
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 1/2] dt-bindings: pwm: Convert imx pwm to json-schema
From: Aisheng Dong @ 2020-05-18 5:58 UTC (permalink / raw)
To: Anson Huang, thierry.reding@gmail.com,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, p.zabel@pengutronix.de,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589439259-28510-1-git-send-email-Anson.Huang@nxp.com>
> From: Anson Huang <Anson.Huang@nxp.com>
> Sent: Thursday, May 14, 2020 2:54 PM
>
> Convert the imx pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 27 ---------
> Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 66
> ++++++++++++++++++++++
> 2 files changed, 66 insertions(+), 27 deletions(-) delete mode 100644
> Documentation/devicetree/bindings/pwm/imx-pwm.txt
> create mode 100644
> Documentation/devicetree/bindings/pwm/imx-pwm.yaml
>
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> deleted file mode 100644
> index 22f1c3d..0000000
> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -Freescale i.MX PWM controller
> -
> -Required properties:
> -- compatible : should be "fsl,<soc>-pwm" and one of the following
> - compatible strings:
> - - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> - - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
> -- reg: physical base address and length of the controller's registers
> -- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> - in this directory for a description of the cells format.
> -- clocks : Clock specifiers for both ipg and per clocks.
> -- clock-names : Clock names should include both "ipg" and "per"
> -See the clock consumer binding,
> - Documentation/devicetree/bindings/clock/clock-bindings.txt
> -- interrupts: The interrupt for the pwm controller
> -
> -Example:
> -
> -pwm1: pwm@53fb4000 {
> - #pwm-cells = <3>;
> - compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> - reg = <0x53fb4000 0x4000>;
> - clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> - <&clks IMX5_CLK_PWM1_HF_GATE>;
> - clock-names = "ipg", "per";
> - interrupts = <61>;
> -};
> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> new file mode 100644
> index 0000000..4b62af2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fschemas%2Fpwm%2Fimx-pwm.yaml%23&data=02%7C01%
> 7Caisheng.d
> +ong%40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc
> 2b4c6fa92c
> +d99c5c301635%7C0%7C0%7C637250366331627865&sdata=M2RPcty
> wz61WZrpAW6S
> +O3NJbr2wj2qXwnMMmBwCbInk%3D&reserved=0
> +$schema:
> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevice
> +tree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Caishen
> g.dong%
> +40nxp.com%7C9b5cc1814a4b47d1cb0d08d7f7d4f594%7C686ea1d3bc2b4c
> 6fa92cd99c
> +5c301635%7C0%7C0%7C637250366331627865&sdata=UxgYSClanyOjt
> BmlyNrMZyF
> +3%2F5awD%2FM3yaVPqgNKgxs%3D&reserved=0
> +
> +title: Freescale i.MX PWM controller
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +properties:
> + "#pwm-cells":
> + description: |
> + Should be 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
> + in this directory for a description of the cells format.
Should we add the reference to pwm.yaml?
BTW, strange, I didn't see format description in pwm.yaml.
> + enum:
> + - 2
> + - 3
> +
> + compatible:
> + enum:
> + - fsl,imx1-pwm
> + - fsl,imx27-pwm
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: SoC PWM ipg clock
> + - description: SoC PWM per clock
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: per
> + maxItems: 2
> +
> + interrupts:
> + maxItems: 1
> +
> +required:
> + - "#pwm-cells"
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx5-clock.h>
> +
> + pwm@53fb4000 {
> + #pwm-cells = <3>;
> + compatible = "fsl,imx27-pwm";
> + reg = <0x53fb4000 0x4000>;
> + clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> + <&clks IMX5_CLK_PWM1_HF_GATE>;
> + clock-names = "ipg", "per";
> + interrupts = <61>;
> + };
> --
> 2.7.4
_______________________________________________
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/3] arm64: perf: Add support for Perf NMI interrupts
From: Sumit Garg @ 2020-05-18 5:46 UTC (permalink / raw)
To: Lecopzer Chen, julien.thierry.kdev
Cc: Mark Rutland, lecopzer.chen, Will Deacon, alexander.shishkin,
Catalin Marinas, yj.chiang, Linux Kernel Mailing List, acme,
Peter Zijlstra, mingo, linux-mediatek, matthias.bgg, namhyung,
jolsa, linux-arm-kernel
In-Reply-To: <20200516124857.75004-1-lecopzer@gmail.com>
+ Julien
Hi Lecopzer,
On Sat, 16 May 2020 at 18:20, Lecopzer Chen <lecopzer@gmail.com> wrote:
>
> These series implement Perf NMI funxtionality and depends on
> Pseudo NMI [1] which has been upstreamed.
>
> In arm64 with GICv3, Pseudo NMI was implemented for NMI-like interruts.
> That can be extended to Perf NMI which is the prerequisite for hard-lockup
> detector which had already a standard interface inside Linux.
>
> Thus the first step we need to implement perf NMI interface and make sure
> it works fine.
>
This is something that is already implemented via Julien's patch-set
[1]. Its v4 has been floating since July, 2019 and I couldn't find any
major blocking comments but not sure why things haven't progressed
further.
Maybe Julien or Arm maintainers can provide updates on existing
patch-set [1] and how we should proceed further with this interesting
feature.
And regarding hard-lockup detection, I have been able to enable it
based on perf NMI events using Julien's perf patch-set [1]. Have a
look at the patch here [2].
[1] https://patchwork.kernel.org/cover/11047407/
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732227.html
-Sumit
> Perf NMI has been test by dd if=/dev/urandom of=/dev/null like the link [2]
> did.
>
> [1] https://lkml.org/lkml/2019/1/31/535
> [2] https://www.linaro.org/blog/debugging-arm-kernels-using-nmifiq
>
>
> Lecopzer Chen (3):
> arm_pmu: Add support for perf NMI interrupts registration
> arm64: perf: Support NMI context for perf event ISR
> arm64: Kconfig: Add support for the Perf NMI
>
> arch/arm64/Kconfig | 10 +++++++
> arch/arm64/kernel/perf_event.c | 36 ++++++++++++++++++------
> drivers/perf/arm_pmu.c | 51 ++++++++++++++++++++++++++++++----
> include/linux/perf/arm_pmu.h | 6 ++++
> 4 files changed, 88 insertions(+), 15 deletions(-)
>
> --
> 2.25.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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] dt-bindings: pwm: Convert mxs pwm to json-schema
From: Anson Huang @ 2020-05-18 5:31 UTC (permalink / raw)
To: Aisheng Dong, thierry.reding@gmail.com,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <AM6PR04MB4966B92CFFA23DD77748C77680B80@AM6PR04MB4966.eurprd04.prod.outlook.com>
> Subject: RE: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema
>
> > +title: Freescale MXS PWM controller
> > +
> > +maintainers:
> > + - Shawn Guo <shawn.guo@linaro.org>
> > + - Anson Huang <anson.huang@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - fsl,imx23-pwm
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#pwm-cells":
> > + const: 3
>
> Seems you missed the reference to pwm.yaml.
It is because many pwm yaml files also has no "#pwm-cells" reference, so I
am NOT sure if it is a MUST:
Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
...
Anson
_______________________________________________
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] dt-bindings: pwm: Convert mxs pwm to json-schema
From: Aisheng Dong @ 2020-05-18 5:21 UTC (permalink / raw)
To: Anson Huang, thierry.reding@gmail.com,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <1589456470-2658-1-git-send-email-Anson.Huang@nxp.com>
> +title: Freescale MXS PWM controller
> +
> +maintainers:
> + - Shawn Guo <shawn.guo@linaro.org>
> + - Anson Huang <anson.huang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - fsl,imx23-pwm
> +
> + reg:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 3
Seems you missed the reference to pwm.yaml.
Regards
Aisheng
> +
> + fsl,pwm-number:
> + $ref: '/schemas/types.yaml#/definitions/uint32'
> + description: u32 value representing the number of PWM devices
> +
> +required:
> + - compatible
> + - reg
> + - "#pwm-cells"
> + - fsl,pwm-number
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + pwm@80064000 {
> + compatible = "fsl,imx23-pwm";
> + reg = <0x80064000 0x2000>;
> + #pwm-cells = <3>;
> + fsl,pwm-number = <8>;
> + };
> --
> 2.7.4
_______________________________________________
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 27/38] xen: gntdev: fix common struct sg_table related issues
From: Jürgen Groß @ 2020-05-18 5:17 UTC (permalink / raw)
To: Marek Szyprowski, dri-devel, iommu, linaro-mm-sig, linux-kernel
Cc: Bartlomiej Zolnierkiewicz, David Airlie, Daniel Vetter, xen-devel,
Boris Ostrovsky, Robin Murphy, Christoph Hellwig,
linux-arm-kernel
In-Reply-To: <20200513133245.6408-27-m.szyprowski@samsung.com>
On 13.05.20 15:32, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Juergen Gross <jgross@suse.com>
Juergen
_______________________________________________
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 v2] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function
From: Inki Dae @ 2020-05-18 5:03 UTC (permalink / raw)
To: Christophe JAILLET, jy0922.shim, sw0312.kim, kyungmin.park,
airlied, daniel, kgene, krzk
Cc: linux-samsung-soc, kernel-janitors, linux-arm-kernel, dri-devel,
linux-kernel
In-Reply-To: <20200516105736.269669-1-christophe.jaillet@wanadoo.fr>
20. 5. 16. 오후 7:57에 Christophe JAILLET 이(가) 쓴 글:
> 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
> This must be released in the error handling path.
Picked it up.
Thanks,
Inki Dae
>
> In order to do that, add an error handling path and move the
> 'exynos_dsi_parse_dt()' call from the beginning to the end of the probe
> function to ease the error handling path.
> This function only sets some variables which are used only in the
> 'transfer' function.
>
> The call chain is:
> .transfer
> --> exynos_dsi_host_transfer
> --> exynos_dsi_init
> --> exynos_dsi_enable_clock (use burst_clk_rate and esc_clk_rate)
> --> exynos_dsi_set_pll (use pll_clk_rate)
>
> While at it, also handle cases where 'component_add()' fails.
>
> This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge node reference in removal")
> which fixed the issue in the remove function.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> A Fixes tag could be required, but I've not been able to figure out which
> one to use.
>
> v2: move around 'exynos_dsi_parse_dt' instead of adding many gotos
> handle component_add failures
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 902938d2568f..a9d24402fabf 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1759,10 +1759,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
> dsi->dev = dev;
> dsi->driver_data = of_device_get_match_data(dev);
>
> - ret = exynos_dsi_parse_dt(dsi);
> - if (ret)
> - return ret;
> -
> dsi->supplies[0].supply = "vddcore";
> dsi->supplies[1].supply = "vddio";
> ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
> @@ -1823,11 +1819,25 @@ static int exynos_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> + ret = exynos_dsi_parse_dt(dsi);
> + if (ret)
> + return ret;
> +
> platform_set_drvdata(pdev, &dsi->encoder);
>
> pm_runtime_enable(dev);
>
> - return component_add(dev, &exynos_dsi_component_ops);
> + ret = component_add(dev, &exynos_dsi_component_ops);
> + if (ret)
> + goto err_disable_runtime;
> +
> + return 0;
> +
> +err_disable_runtime:
> + pm_runtime_disable(dev);
> + of_node_put(dsi->in_bridge_node);
> +
> + return ret;
> }
>
> static int exynos_dsi_remove(struct platform_device *pdev)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [stericsson:ux500-dts] BUILD SUCCESS 4908471e1ed767504ccfe3561e3a72c7458b1138
From: kbuild test robot @ 2020-05-18 4:48 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git ux500-dts
branch HEAD: 4908471e1ed767504ccfe3561e3a72c7458b1138 ARM: dts: ux500: Add touchscreen to the Skomer
elapsed time: 484m
configs tested: 74
configs skipped: 112
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
sh sh03_defconfig
arm vf610m4_defconfig
h8300 defconfig
arm efm32_defconfig
arm shmobile_defconfig
arm tct_hammer_defconfig
arm cns3420vb_defconfig
arm pleb_defconfig
h8300 alldefconfig
microblaze mmu_defconfig
powerpc ppc44x_defconfig
arm colibri_pxa300_defconfig
arm clps711x_defconfig
arm magician_defconfig
arm h3600_defconfig
ia64 allnoconfig
mips loongson3_defconfig
powerpc64 alldefconfig
m68k m5307c3_defconfig
mips nlm_xlr_defconfig
sh migor_defconfig
powerpc mpc512x_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a004-20200518
i386 randconfig-a002-20200518
x86_64 randconfig-a016-20200518
x86_64 randconfig-a012-20200518
x86_64 randconfig-a015-20200518
x86_64 randconfig-a013-20200518
x86_64 randconfig-a011-20200518
x86_64 randconfig-a014-20200518
i386 randconfig-a012-20200518
i386 randconfig-a014-20200518
i386 randconfig-a016-20200518
i386 randconfig-a011-20200518
i386 randconfig-a015-20200518
i386 randconfig-a013-20200518
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
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: dts: imx7d-pinfunc: add input mux for ENET2 mdio
From: Andy Duan @ 2020-05-18 4:35 UTC (permalink / raw)
To: Aisheng Dong, Steffen Trumtrar, Shawn Guo
Cc: linux-arm-kernel@lists.infradead.org, Rob Herring, Fabio Estevam,
dl-linux-imx, Pengutronix Kernel Team
In-Reply-To: <AM6PR04MB4966710261BD821190B2F0FD80B80@AM6PR04MB4966.eurprd04.prod.outlook.com>
From: Aisheng Dong <aisheng.dong@nxp.com> Sent: Monday, May 18, 2020 11:55 AM
> > From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > Sent: Friday, May 15, 2020 7:42 PM
> >
> > Add the missing input mux for ENET2 mdio. Without this setting, it is
> > not possible to read the MDIO answers back from the PHY.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/boot/dts/imx7d-pinfunc.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h
> > b/arch/arm/boot/dts/imx7d-pinfunc.h
> > index 08ca1608fdb1..69f2c1ec8254 100644
> > --- a/arch/arm/boot/dts/imx7d-pinfunc.h
> > +++ b/arch/arm/boot/dts/imx7d-pinfunc.h
> > @@ -592,7 +592,7 @@
> > #define MX7D_PAD_UART2_RX_DATA__ECSPI1_SS3
> > 0x0130 0x03A0 0x0000 0x3 0x0
> > #define MX7D_PAD_UART2_RX_DATA__ENET2_1588_EVENT1_IN
> > 0x0130 0x03A0 0x0000 0x4 0x0
> > #define MX7D_PAD_UART2_RX_DATA__GPIO4_IO2
> > 0x0130 0x03A0 0x0000 0x5 0x0
> > -#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> > 0x0130 0x03A0 0x0000 0x6 0x0
> > +#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> > 0x0130 0x03A0 0x0574 0x6 0x1
>
> It's strange that I didn't find this select input setting from latest RM.
> Anything I missed?
>
> Also copy Andy to comment.
>
Check the RM in my local, it define the signal select input from UART2_RX_DATA,
it is correct with the change.
Aisheng, we can check together for our RM version.
> Regards
> Aisheng
>
> > #define MX7D_PAD_UART2_TX_DATA__UART2_DCE_TX
> > 0x0134 0x03A4 0x0000 0x0 0x0
> > #define MX7D_PAD_UART2_TX_DATA__UART2_DTE_RX
> > 0x0134 0x03A4 0x06FC 0x0 0x3
> > #define MX7D_PAD_UART2_TX_DATA__I2C2_SDA
> > 0x0134 0x03A4 0x05E0 0x1 0x0
> > --
> > 2.26.2
_______________________________________________
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 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Guenter Roeck @ 2020-05-18 4:29 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200518034938.GA3023182@iweiny-DESK2.sc.intel.com>
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
> > > From: Ira Weiny <ira.weiny@intel.com>
> > >
> > > Every single architecture (including !CONFIG_HIGHMEM) calls...
> > >
> > > pagefault_enable();
> > > preempt_enable();
> > >
> > > ... before returning from __kunmap_atomic(). Lift this code into the
> > > kunmap_atomic() macro.
> > >
> > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > > be consistent.
> > >
> > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >
> > This patch results in:
> >
> > Starting init: /bin/sh exists but couldn't execute it (error -14)
> >
> > when trying to boot microblazeel:petalogix-ml605 in qemu.
>
> Thanks for the report. I'm not readily seeing the issue.
>
> Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
>
See below. Yes, CONFIG_HIGHMEM is set.
The scripts used to build and boot the image are at:
https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel
Hope this helps,
Guenter
---
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_AUDIT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BASE_FULL is not set
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_KERNEL_BASE_ADDR=0x50000000
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_BARREL=1
CONFIG_XILINX_MICROBLAZE0_USE_DIV=1
CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2
CONFIG_XILINX_MICROBLAZE0_USE_FPU=2
CONFIG_XILINX_MICROBLAZE0_HW_VER="10.0.a"
CONFIG_HZ_100=y
CONFIG_MMU=y
CONFIG_HIGHMEM=y
CONFIG_PCI_XILINX=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_EFI_PARTITION is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IPV6 is not set
CONFIG_BRIDGE=m
CONFIG_PCI=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_NETDEVICES=y
CONFIG_XILINX_EMACLITE=y
CONFIG_XILINX_LL_TEMAC=y
# CONFIG_INPUT is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_XILINX_HWICAP=y
CONFIG_I2C=y
CONFIG_I2C_XILINX=y
CONFIG_SPI=y
CONFIG_SPI_XILINX=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_XILINX_WATCHDOG=y
CONFIG_FB=y
CONFIG_FB_XILINX=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_DMEM_GENIRQ=y
CONFIG_EXT2_FS=y
# CONFIG_DNOTIFY is not set
CONFIG_CRAMFS=y
CONFIG_ROMFS_FS=y
CONFIG_NFS_FS=y
CONFIG_CIFS=y
CONFIG_CIFS_STATS2=y
CONFIG_ENCRYPTED_KEYS=y
CONFIG_DEBUG_INFO=y
CONFIG_KGDB=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_KDB=y
CONFIG_DEBUG_SLAB=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_SPINLOCK=y
_______________________________________________
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 v6 09/10] arm64: efi: Export screen_info
From: Nikhil Mahale @ 2020-05-18 4:25 UTC (permalink / raw)
To: Michael Kelley, Arnd Bergmann
Cc: Mark Rutland, linux-arch, linux-hyperv@vger.kernel.org, linux-efi,
Boqun Feng, gregkh, Catalin Marinas, Jason Wang, Sunil Muthuswamy,
linux-kernel@vger.kernel.org, marcelo.cerri@canonical.com,
olaf@aepfle.de, Marc Zyngier, Andy Whitcroft, vkuznets,
KY Srinivasan, Will Deacon, Ard Biesheuvel, Linux ARM
In-Reply-To: <f2b63853-24ae-d6b7-cd43-5792c0d4d31b@nvidia.com>
On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> On 3/20/20 3:16 AM, Michael Kelley wrote:
>> From: Arnd Bergmann <arnd@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
>>>
>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
>>>> From: Arnd Bergmann <arnd@arndb.de>
>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> wrote:
>>>>>>
>>>>>> The Hyper-V frame buffer driver may be built as a module, and
>>>>>> it needs access to screen_info. So export screen_info.
>>>>>>
>>>>>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
>>>>>
>>>>> Is there any chance of using a more modern KMS based driver for the screen
>>>>> than the old fbdev subsystem? I had hoped to one day completely remove
>>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
>>>>> architectures.
>>>>>
>>>>
>>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
>>>> frame buffer device. That driver builds and runs on both ARM64 and x86.
>>>>
>>>> I'm not knowledgeable about video/graphics drivers, but when you
>>>> say "a more modern KMS based driver", are you meaning one based on
>>>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device?
>>>> Are there any drivers that would be a good pattern to look at?
>>>
>>> It used to be a lot harder to write a DRM driver compared to an fbdev
>>> driver, but this has changed to the opposite over the years.
>>>
>>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
>>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
>>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
>>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
>>>
>>
>> Thanks for the pointers, especially for the other hypervisors.
>>
> Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
> I had configured by email client incorrectly to reply.
>
> screen_info is still useful with a modern KMS-based driver. It exposes
> the mode parameters that the GOP driver chose. This information is
> needed to implement seamless or glitchless boot, by both ensuring that
> the scanout parameters don't change and being able to read back the
> scanout image to populate the initial contents of the new surface.
>
> This works today on arches which implement (U)EFI and export
> screen_info, including x86 and powerpc, but doesn't work on arm or
> arm64. As arm64 systems that implement UEFI with real GOP drivers
> become more prevalent, it would be nice to be have these features there
> as well.
In addition to this, even if a driver doesn't implement a framebuffer
console, or if it does but has an option to disable it, the driver still
needs to know whether the EFI console is using resources on the GPU so
it can avoid clobbering them. For example screen_info provides information
like offset and size of EFI console, using this information driver can
reserve memory used by console and prevent corruption on it.
I think arm64 should export screen_info.
> Thanks,
> Nikhil Mahale
>
>> Michael
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 1/2] arm64: tlb: Detect the ARMv8.4 TLBI RANGE feature
From: Anshuman Khandual @ 2020-05-18 4:22 UTC (permalink / raw)
To: Zhenyu Ye, Mark Rutland
Cc: linux-arch, maz, suzuki.poulose, catalin.marinas, linux-kernel,
xiexiangyou, steven.price, zhangshaokun, linux-mm, arm,
prime.zeng, guohanjun, olof, kuhn.chenqun, will, linux-arm-kernel
In-Reply-To: <cb9d32b6-a9d8-3737-e69d-df4191b7afa9@huawei.com>
On 05/11/2020 05:55 PM, Zhenyu Ye wrote:
> On 2020/5/5 18:14, Mark Rutland wrote:
>> On Tue, Apr 14, 2020 at 07:28:34PM +0800, Zhenyu Ye wrote:
>>> ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a
>>> range of input addresses. This patch detect this feature.
>>>
>>> Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com>
>>> ---
>>> arch/arm64/include/asm/cpucaps.h | 3 ++-
>>> arch/arm64/include/asm/sysreg.h | 4 ++++
>>> arch/arm64/kernel/cpufeature.c | 11 +++++++++++
>>> 3 files changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
>>> index 8eb5a088ae65..950095a72617 100644
>>> --- a/arch/arm64/include/asm/cpucaps.h
>>> +++ b/arch/arm64/include/asm/cpucaps.h
>>> @@ -61,7 +61,8 @@
>>> #define ARM64_HAS_AMU_EXTN 51
>>> #define ARM64_HAS_ADDRESS_AUTH 52
>>> #define ARM64_HAS_GENERIC_AUTH 53
>>> +#define ARM64_HAS_TLBI_RANGE 54
>>>
>>> -#define ARM64_NCAPS 54
>>> +#define ARM64_NCAPS 55
>>>
>>> #endif /* __ASM_CPUCAPS_H */
>>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>>> index ebc622432831..ac1b98650234 100644
>>> --- a/arch/arm64/include/asm/sysreg.h
>>> +++ b/arch/arm64/include/asm/sysreg.h
>>> @@ -592,6 +592,7 @@
>>>
>>> /* id_aa64isar0 */
>>> #define ID_AA64ISAR0_RNDR_SHIFT 60
>>> +#define ID_AA64ISAR0_TLBI_RANGE_SHIFT 56
>>> #define ID_AA64ISAR0_TS_SHIFT 52
>>> #define ID_AA64ISAR0_FHM_SHIFT 48
>>> #define ID_AA64ISAR0_DP_SHIFT 44
>>> @@ -605,6 +606,9 @@
>>> #define ID_AA64ISAR0_SHA1_SHIFT 8
>>> #define ID_AA64ISAR0_AES_SHIFT 4
>>>
>>> +#define ID_AA64ISAR0_TLBI_RANGE_NI 0x0
>>> +#define ID_AA64ISAR0_TLBI_RANGE 0x2
>>> +
>>> /* id_aa64isar1 */
>>> #define ID_AA64ISAR1_I8MM_SHIFT 52
>>> #define ID_AA64ISAR1_DGH_SHIFT 48
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 9fac745aa7bb..31bcfd0722b5 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -124,6 +124,7 @@ static bool __system_matches_cap(unsigned int n);
>>> */
>>> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
>>> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TLBI_RANGE_SHIFT, 4, 0),
Hello Zhenyu,
This is already being added through another patch [1] in a series [2] which primarily
has cpufeature changes. I will soon update the series making this feature FTR_HIDDEN.
[1] https://patchwork.kernel.org/patch/11523881/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=281211
I am planning to respin the series (V4) based on arm64 tree (for-next/cpufeature). So
could you please rebase this patch (probably dropping cpufeature related changes) on
upcoming V4, so that all the changes will be based on arm64 tree (for-next/cpufeature).
- Anshuman
_______________________________________________
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: dts: imx7d-pinfunc: add input mux for ENET2 mdio
From: Aisheng Dong @ 2020-05-18 3:54 UTC (permalink / raw)
To: Steffen Trumtrar, Shawn Guo, Andy Duan
Cc: linux-arm-kernel@lists.infradead.org, Rob Herring, Fabio Estevam,
dl-linux-imx, Pengutronix Kernel Team
In-Reply-To: <20200515114151.6516-1-s.trumtrar@pengutronix.de>
> From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Sent: Friday, May 15, 2020 7:42 PM
>
> Add the missing input mux for ENET2 mdio. Without this setting, it is not
> possible to read the MDIO answers back from the PHY.
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> arch/arm/boot/dts/imx7d-pinfunc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h
> b/arch/arm/boot/dts/imx7d-pinfunc.h
> index 08ca1608fdb1..69f2c1ec8254 100644
> --- a/arch/arm/boot/dts/imx7d-pinfunc.h
> +++ b/arch/arm/boot/dts/imx7d-pinfunc.h
> @@ -592,7 +592,7 @@
> #define MX7D_PAD_UART2_RX_DATA__ECSPI1_SS3
> 0x0130 0x03A0 0x0000 0x3 0x0
> #define MX7D_PAD_UART2_RX_DATA__ENET2_1588_EVENT1_IN
> 0x0130 0x03A0 0x0000 0x4 0x0
> #define MX7D_PAD_UART2_RX_DATA__GPIO4_IO2
> 0x0130 0x03A0 0x0000 0x5 0x0
> -#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> 0x0130 0x03A0 0x0000 0x6 0x0
> +#define MX7D_PAD_UART2_RX_DATA__ENET2_MDIO
> 0x0130 0x03A0 0x0574 0x6 0x1
It's strange that I didn't find this select input setting from latest RM.
Anything I missed?
Also copy Andy to comment.
Regards
Aisheng
> #define MX7D_PAD_UART2_TX_DATA__UART2_DCE_TX
> 0x0134 0x03A4 0x0000 0x0 0x0
> #define MX7D_PAD_UART2_TX_DATA__UART2_DTE_RX
> 0x0134 0x03A4 0x06FC 0x0 0x3
> #define MX7D_PAD_UART2_TX_DATA__I2C2_SDA
> 0x0134 0x03A4 0x05E0 0x1 0x0
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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