* RE: [PATCH 1/2] dt-bindings: imx-ocotp: Add i.MX8MN compatible
From: Anson Huang @ 2019-08-06 5:59 UTC (permalink / raw)
To: srinivas.kandagatla@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <20190711023714.16000-1-Anson.Huang@nxp.com>
Gentle Ping...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add compatible for i.MX8MN and add i.MX8MM/i.MX8MN to the description.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 96ffd06..904dadf 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -2,7 +2,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device
> tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, -
> i.MX7D/S, i.MX7ULP and i.MX8MQ SoCs.
> +i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM and i.MX8MN SoCs.
>
> Required properties:
> - compatible: should be one of
> @@ -16,6 +16,7 @@ Required properties:
> "fsl,imx7ulp-ocotp" (i.MX7ULP),
> "fsl,imx8mq-ocotp" (i.MX8MQ),
> "fsl,imx8mm-ocotp" (i.MX8MM),
> + "fsl,imx8mn-ocotp" (i.MX8MN),
> followed by "syscon".
> - #address-cells : Should be 1
> - #size-cells : Should be 1
> --
> 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
* [PATCH v2] arm64: dts: ls1028a: Add Thermal Monitor Unit node
From: Yuantian Tang @ 2019-08-06 5:35 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, Yuantian Tang, linux-kernel, leoyang.li,
robh+dt, linux-arm-kernel
The Thermal Monitoring Unit (TMU) monitors and reports the
temperature from 2 remote temperature measurement sites
located on ls1028a chip.
Add TMU dts node to enable this feature.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
---
v2:
- remove multiple sensors support
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 85 +++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06a98d5..20d7e7db5dcb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -29,6 +29,7 @@
clocks = <&clockgen 1 0>;
next-level-cache = <&l2>;
cpu-idle-states = <&CPU_PW20>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -39,6 +40,7 @@
clocks = <&clockgen 1 0>;
next-level-cache = <&l2>;
cpu-idle-states = <&CPU_PW20>;
+ #cooling-cells = <2>;
};
l2: l2-cache {
@@ -503,6 +505,89 @@
status = "disabled";
};
+ tmu: tmu@1f00000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0x0 0x1f80000 0x0 0x10000>;
+ interrupts = <0 23 0x4>;
+ fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x70061>;
+ fsl,tmu-calibration = <0x00000000 0x00000024
+ 0x00000001 0x0000002b
+ 0x00000002 0x00000031
+ 0x00000003 0x00000038
+ 0x00000004 0x0000003f
+ 0x00000005 0x00000045
+ 0x00000006 0x0000004c
+ 0x00000007 0x00000053
+ 0x00000008 0x00000059
+ 0x00000009 0x00000060
+ 0x0000000a 0x00000066
+ 0x0000000b 0x0000006d
+
+ 0x00010000 0x0000001c
+ 0x00010001 0x00000024
+ 0x00010002 0x0000002c
+ 0x00010003 0x00000035
+ 0x00010004 0x0000003d
+ 0x00010005 0x00000045
+ 0x00010006 0x0000004d
+ 0x00010007 0x00000045
+ 0x00010008 0x0000005e
+ 0x00010009 0x00000066
+ 0x0001000a 0x0000006e
+
+ 0x00020000 0x00000018
+ 0x00020001 0x00000022
+ 0x00020002 0x0000002d
+ 0x00020003 0x00000038
+ 0x00020004 0x00000043
+ 0x00020005 0x0000004d
+ 0x00020006 0x00000058
+ 0x00020007 0x00000063
+ 0x00020008 0x0000006e
+
+ 0x00030000 0x00000010
+ 0x00030001 0x0000001c
+ 0x00030002 0x00000029
+ 0x00030003 0x00000036
+ 0x00030004 0x00000042
+ 0x00030005 0x0000004f
+ 0x00030006 0x0000005b
+ 0x00030007 0x00000068>;
+ little-endian;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal-zones {
+ core-cluster {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&tmu 0>;
+
+ trips {
+ core_cluster_alert: core-cluster-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ core_cluster_crit: core-cluster-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&core_cluster_alert>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
pcie@1f0000000 { /* Integrated Endpoint Root Complex */
compatible = "pci-host-ecam-generic";
reg = <0x01 0xf0000000 0x0 0x100000>;
--
2.17.1
_______________________________________________
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 v4] kasan: add memory corruption identification for software tag-based mode
From: Walter Wu @ 2019-08-06 5:43 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Andrew Morton, Martin Schwidefsky,
Arnd Bergmann, Thomas Gleixner, Vasily Gorbik, Andrey Konovalov,
Miles Chen, Walter Wu
Cc: wsd_upstream, linux-kernel, kasan-dev, linux-mm, linux-mediatek,
linux-arm-kernel
This patch adds memory corruption identification at bug report for
software tag-based mode, the report show whether it is "use-after-free"
or "out-of-bound" error instead of "invalid-access" error. This will make
it easier for programmers to see the memory corruption problem.
We extend the slab to store five old free pointer tag and free backtrace,
we can check if the tagged address is in the slab record and make a
good guess if the object is more like "use-after-free" or "out-of-bound".
therefore every slab memory corruption can be identified whether it's
"use-after-free" or "out-of-bound".
====== Changes
Change since v1:
- add feature option CONFIG_KASAN_SW_TAGS_IDENTIFY.
- change QUARANTINE_FRACTION to reduce quarantine size.
- change the qlist order in order to find the newest object in quarantine
- reduce the number of calling kmalloc() from 2 to 1 time.
- remove global variable to use argument to pass it.
- correct the amount of qobject cache->size into the byes of qlist_head.
- only use kasan_cache_shrink() to shink memory.
Change since v2:
- remove the shinking memory function kasan_cache_shrink()
- modify the description of the CONFIG_KASAN_SW_TAGS_IDENTIFY
- optimize the quarantine_find_object() and qobject_free()
- fix the duplicating function name 3 times in the header.
- modify the function name set_track() to kasan_set_track()
Change since v3:
- change tag-based quarantine to extend slab to identify memory corruption
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
---
lib/Kconfig.kasan | 8 ++++
mm/kasan/common.c | 14 +++++--
mm/kasan/kasan.h | 37 ++++++++++++++++++
mm/kasan/report.c | 53 +++++++++++++++-----------
mm/kasan/tags.c | 86 ++++++++++++++++++++++++++++++++++++++++++
mm/kasan/tags_report.c | 5 ++-
6 files changed, 177 insertions(+), 26 deletions(-)
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fafba1a923b..70b55e1c4834 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -135,6 +135,14 @@ config KASAN_S390_4_LEVEL_PAGING
to 3TB of RAM with KASan enabled). This options allows to force
4-level paging instead.
+config KASAN_SW_TAGS_IDENTIFY
+ bool "Enable memory corruption identification"
+ depends on KASAN_SW_TAGS
+ help
+ This option enables best-effort identification of bug type
+ (use-after-free or out-of-bounds) at the cost of increased
+ memory consumption for slab extending.
+
config TEST_KASAN
tristate "Module for testing KASAN for bug detection"
depends on m && KASAN
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2277b82902d8..6bbb044708e6 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -71,7 +71,7 @@ static inline depot_stack_handle_t 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 = save_stack(flags);
@@ -304,7 +304,8 @@ size_t kasan_metadata_size(struct kmem_cache *cache)
struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
const void *object)
{
- BUILD_BUG_ON(sizeof(struct kasan_alloc_meta) > 32);
+ if (!IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ BUILD_BUG_ON(sizeof(struct kasan_alloc_meta) > 32);
return (void *)object + cache->kasan_info.alloc_meta_offset;
}
@@ -446,7 +447,11 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
unlikely(!(cache->flags & SLAB_KASAN)))
return false;
- set_track(&get_alloc_info(cache, object)->free_track, GFP_NOWAIT);
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ kasan_set_free_info(cache, object, tag);
+ else
+ kasan_set_track(&get_alloc_info(cache, object)->free_track,
+ GFP_NOWAIT);
quarantine_put(get_free_info(cache, object), cache);
return IS_ENABLED(CONFIG_KASAN_GENERIC);
@@ -484,7 +489,8 @@ 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/kasan.h b/mm/kasan/kasan.h
index 014f19e76247..531a5823e8c6 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -95,9 +95,23 @@ struct kasan_track {
depot_stack_handle_t stack;
};
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+#define KASAN_EXTRA_FREE_INFO_COUNT 4
+#define KASAN_TOTAL_FREE_INFO_COUNT (KASAN_EXTRA_FREE_INFO_COUNT + 1)
+struct extra_free_info {
+ /* Round-robin FIFO array. */
+ struct kasan_track free_track[KASAN_EXTRA_FREE_INFO_COUNT];
+ u8 free_pointer_tag[KASAN_TOTAL_FREE_INFO_COUNT];
+ u8 free_track_tail;
+};
+#endif
+
struct kasan_alloc_meta {
struct kasan_track alloc_track;
struct kasan_track free_track;
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ struct extra_free_info free_info;
+#endif
};
struct qlist_node {
@@ -146,6 +160,29 @@ void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
void kasan_report_invalid_free(void *object, unsigned long ip);
+struct page *addr_to_page(const void *addr);
+
+void kasan_set_track(struct kasan_track *track, gfp_t flags);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+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);
+char *kasan_get_corruption_type(void *addr);
+#else
+static inline void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag) { }
+static inline struct kasan_track *kasan_get_free_track(
+ struct kmem_cache *cache, void *object, u8 tag)
+{
+ return NULL;
+}
+static inline char *kasan_get_corruption_type(void *addr)
+{
+ return NULL;
+}
+#endif
+
#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 0e5f965f1882..9ea7a4265b42 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -111,14 +111,6 @@ static void print_track(struct kasan_track *track, const char *prefix)
}
}
-static struct page *addr_to_page(const void *addr)
-{
- if ((addr >= (void *)PAGE_OFFSET) &&
- (addr < high_memory))
- return virt_to_head_page(addr);
- return NULL;
-}
-
static void describe_object_addr(struct kmem_cache *cache, void *object,
const void *addr)
{
@@ -152,18 +144,27 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
}
static void describe_object(struct kmem_cache *cache, void *object,
- const void *addr)
+ const void *tagged_addr)
{
+ void *untagged_addr = reset_tag(tagged_addr);
struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
if (cache->flags & SLAB_KASAN) {
print_track(&alloc_info->alloc_track, "Allocated");
pr_err("\n");
- print_track(&alloc_info->free_track, "Freed");
- pr_err("\n");
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY)) {
+ struct kasan_track *free_track;
+ u8 tag = get_tag(tagged_addr);
+
+ free_track = kasan_get_free_track(cache, object, tag);
+ print_track(free_track, "Freed");
+ } else {
+ print_track(&alloc_info->free_track, "Freed");
+ pr_err("\n");
+ }
}
- describe_object_addr(cache, object, addr);
+ describe_object_addr(cache, object, untagged_addr);
}
static inline bool kernel_or_module_addr(const void *addr)
@@ -344,23 +345,25 @@ static void print_address_stack_frame(const void *addr)
print_decoded_frame_descr(frame_descr);
}
-static void print_address_description(void *addr)
+static void print_address_description(void *tagged_addr)
{
- struct page *page = addr_to_page(addr);
+ void *untagged_addr = reset_tag(tagged_addr);
+ struct page *page = addr_to_page(untagged_addr);
dump_stack();
pr_err("\n");
if (page && PageSlab(page)) {
struct kmem_cache *cache = page->slab_cache;
- void *object = nearest_obj(cache, page, addr);
+ void *object = nearest_obj(cache, page, untagged_addr);
- describe_object(cache, object, addr);
+ describe_object(cache, object, tagged_addr);
}
- if (kernel_or_module_addr(addr) && !init_task_stack_addr(addr)) {
+ if (kernel_or_module_addr(untagged_addr) &&
+ !init_task_stack_addr(untagged_addr)) {
pr_err("The buggy address belongs to the variable:\n");
- pr_err(" %pS\n", addr);
+ pr_err(" %pS\n", tagged_addr);
}
if (page) {
@@ -368,7 +371,7 @@ static void print_address_description(void *addr)
dump_page(page, "kasan: bad access detected");
}
- print_address_stack_frame(addr);
+ print_address_stack_frame(untagged_addr);
}
static bool row_is_guilty(const void *row, const void *guilty)
@@ -432,6 +435,14 @@ static bool report_enabled(void)
return !test_and_set_bit(KASAN_BIT_REPORTED, &kasan_flags);
}
+struct page *addr_to_page(const void *addr)
+{
+ if ((addr >= (void *)PAGE_OFFSET) &&
+ (addr < high_memory))
+ return virt_to_head_page(addr);
+ return NULL;
+}
+
void kasan_report_invalid_free(void *object, unsigned long ip)
{
unsigned long flags;
@@ -439,10 +450,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip)
start_report(&flags);
pr_err("BUG: KASAN: double-free or invalid-free in %pS\n", (void *)ip);
print_tags(get_tag(object), reset_tag(object));
- object = reset_tag(object);
pr_err("\n");
print_address_description(object);
pr_err("\n");
+ object = reset_tag(object);
print_shadow_for_address(object);
end_report(&flags);
}
@@ -479,7 +490,7 @@ void __kasan_report(unsigned long addr, size_t size, bool is_write, unsigned lon
pr_err("\n");
if (addr_has_shadow(untagged_addr)) {
- print_address_description(untagged_addr);
+ print_address_description(tagged_addr);
pr_err("\n");
print_shadow_for_address(info.first_bad_addr);
} else {
diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
index 0e987c9ca052..05a11f1cfff7 100644
--- a/mm/kasan/tags.c
+++ b/mm/kasan/tags.c
@@ -161,3 +161,89 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
kasan_poison_shadow((void *)addr, size, tag);
}
EXPORT_SYMBOL(__hwasan_tag_memory);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ struct extra_free_info *free_info;
+ u8 idx;
+
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ if (free_info->free_track_tail == 0)
+ free_info->free_track_tail = KASAN_EXTRA_FREE_INFO_COUNT;
+ else
+ free_info->free_track_tail -= 1;
+
+ idx = free_info->free_track_tail;
+ free_info->free_pointer_tag[idx] = tag;
+
+ if (idx == KASAN_EXTRA_FREE_INFO_COUNT)
+ kasan_set_track(&alloc_meta->free_track, GFP_NOWAIT);
+ else
+ kasan_set_track(&free_info->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;
+ struct extra_free_info *free_info;
+ int idx, i;
+
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ for (i = 0; i < KASAN_TOTAL_FREE_INFO_COUNT; i++) {
+ idx = free_info->free_track_tail + i;
+ if (idx >= KASAN_TOTAL_FREE_INFO_COUNT)
+ idx -= KASAN_TOTAL_FREE_INFO_COUNT;
+
+ if (free_info->free_pointer_tag[idx] == tag) {
+ if (idx == KASAN_EXTRA_FREE_INFO_COUNT)
+ return &alloc_meta->free_track;
+ else
+ return &free_info->free_track[idx];
+ }
+ }
+ if (free_info->free_track_tail == KASAN_EXTRA_FREE_INFO_COUNT)
+ return &alloc_meta->free_track;
+ else
+ return &free_info->free_track[free_info->free_track_tail];
+}
+
+char *kasan_get_corruption_type(void *addr)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ struct extra_free_info *free_info;
+ struct page *page;
+ struct kmem_cache *cache;
+ void *object;
+ u8 tag;
+ int idx, i;
+
+ tag = get_tag(addr);
+ addr = reset_tag(addr);
+ page = addr_to_page(addr);
+ if (page && PageSlab(page)) {
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ for (i = 0; i < KASAN_TOTAL_FREE_INFO_COUNT; i++) {
+ idx = free_info->free_track_tail + i;
+ if (idx >= KASAN_TOTAL_FREE_INFO_COUNT)
+ idx -= KASAN_TOTAL_FREE_INFO_COUNT;
+
+ if (free_info->free_pointer_tag[idx] == tag)
+ return "use-after-free";
+ }
+ return "out-of-bounds";
+ }
+ return "invalid-access";
+}
+#endif
diff --git a/mm/kasan/tags_report.c b/mm/kasan/tags_report.c
index 8eaf5f722271..6d8cdb91c4b6 100644
--- a/mm/kasan/tags_report.c
+++ b/mm/kasan/tags_report.c
@@ -36,7 +36,10 @@
const char *get_bug_type(struct kasan_access_info *info)
{
- return "invalid-access";
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ return(kasan_get_corruption_type((void *)info->access_addr));
+ else
+ return "invalid-access";
}
void *find_first_bad_addr(void *addr, size_t size)
--
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 V4 1/4] dt-bindings: arm: imx: Add the soc binding for i.MX8MN
From: Anson Huang @ 2019-08-06 5:42 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
andrew.smirnov@gmail.com, manivannan.sadhasivam@linaro.org,
j.neuschaefer@gmx.net, u.kleine-koenig@pengutronix.de, Leo Li,
Aisheng Dong, l.stach@pengutronix.de, Vabhav Sharma,
Bhaskar Upadhaya, Jacky Bai, Pramod Kumar, Leonard Crestez,
Daniel Baluta, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <20190619022145.42398-1-Anson.Huang@nxp.com>
Ping for this patch series...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> This patch adds the soc & board binding for i.MX8MN.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> No change.
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 407138e..b35abb1 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -177,6 +177,12 @@ properties:
> - fsl,imx8mm-evk # i.MX8MM EVK Board
> - const: fsl,imx8mm
>
> + - description: i.MX8MN based Boards
> + items:
> + - enum:
> + - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
> + - const: fsl,imx8mn
> +
> - description: i.MX8QXP based Boards
> items:
> - enum:
> --
> 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 v3] arm64: dts: ls1028a: Add temperature sensor node
From: Andy Tang @ 2019-08-06 5:41 UTC (permalink / raw)
To: Andy Tang, shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190806053004.36956-1-andy.tang@nxp.com>
Please ignore this email. Sorry for sending the wrong patch.
BR,
Andy
> -----Original Message-----
> From: Yuantian Tang <andy.tang@nxp.com>
> Sent: 2019年8月6日 13:30
> To: shawnguo@kernel.org
> Cc: Leo Li <leoyang.li@nxp.com>; robh+dt@kernel.org;
> mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Tang
> <andy.tang@nxp.com>
> Subject: [PATCH v3] arm64: dts: ls1028a: Add temperature sensor node
>
> Add nxp sa56004 chip node for temperature monitor.
>
> Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
> ---
> v3:
> - sort the node in i2c address
> v2:
> - change the node name and add vcc-supply
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15
> +++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15
> +++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index b359068..960daf2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -47,6 +47,15 @@
> regulator-always-on;
> };
>
> + sb_3v3: regulator-sb3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_vbus";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> @@ -117,6 +126,12 @@
> #size-cells = <0>;
> reg = <0x3>;
>
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
> + vcc-supply = <&sb_3v3>;
> + };
> +
> rtc@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index f9c272f..6a22423 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -43,6 +43,15 @@
> regulator-always-on;
> };
>
> + sb_3v3: regulator-sb3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_vbus";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> @@ -115,6 +124,12 @@
> #size-cells = <0>;
> reg = <0x3>;
>
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
> + vcc-supply = <&sb_3v3>;
> + };
> +
> rtc@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> --
> 1.7.1
_______________________________________________
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] arm64: dts: ls1028a: Add temperature sensor node
From: Yuantian Tang @ 2019-08-06 5:30 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, Yuantian Tang, linux-kernel, leoyang.li,
robh+dt, linux-arm-kernel
Add nxp sa56004 chip node for temperature monitor.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
v3:
- sort the node in i2c address
v2:
- change the node name and add vcc-supply
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15 +++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index b359068..960daf2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -47,6 +47,15 @@
regulator-always-on;
};
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -117,6 +126,12 @@
#size-cells = <0>;
reg = <0x3>;
+ temperature-sensor@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ vcc-supply = <&sb_3v3>;
+ };
+
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index f9c272f..6a22423 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -43,6 +43,15 @@
regulator-always-on;
};
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -115,6 +124,12 @@
#size-cells = <0>;
reg = <0x3>;
+ temperature-sensor@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ vcc-supply = <&sb_3v3>;
+ };
+
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
--
1.7.1
_______________________________________________
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 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Christoph Hellwig @ 2019-08-06 5:29 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linuxppc-dev,
x86, linux-m68k, linux-kernel, iommu, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <s5hzhkonf0k.wl-tiwai@suse.de>
On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> This won't work as expected, unfortunately. It's a bit tricky check,
> since the driver may have its own mmap implementation via
> substream->ops->mmap, and the dma_buffer.dev.dev might point to
> another object depending on the dma_buffer.dev.type.
>
> So please replace with something like below:
From my gut feeling I'd reorder it a bit to make it more clear like
this:
http://git.infradead.org/users/hch/misc.git/commitdiff/958fccf54d00c16740522f818d23f9350498e911
if this is fine it'll be in the next version, waiting for a little more
feedback on the other patches.
_______________________________________________
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] ARM: zynq: support smp in thumb mode
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-2-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:17PM -0400, Luis Araneda wrote:
> Add .arm directive to headsmp.S to ensure that the
> CPU starts in 32-bit ARM mode and the correct code
> size is copied on smp bring-up
>
> Additionally, start secondary CPUs on secondary_startup_arm
> to automatically switch from ARM to thumb on a thumb kernel
>
> Suggested-by: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/headsmp.S | 2 ++
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
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] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-3-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:18PM -0400, Luis Araneda wrote:
> This fixes a kernel panic (read overflow) on memcpy when
> FORTIFY_SOURCE is enabled.
>
> The computed size of memcpy args are:
> - p_size (dst): 4294967295 = (size_t) -1
> - q_size (src): 1
> - size (len): 8
>
> Additionally, the memory is marked as __iomem, so one of
> the memcpy_* functions should be used for read/write
>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
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/2] ARM: zynq: smp improvements
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:16PM -0400, Luis Araneda wrote:
> This series adds support for kernel compiled in Thumb mode
> and fixes a kernel panic on smp bring-up when FORTIFY_SOURCE
> is enabled.
>
> The series started with the second patch as an RFC, and
> the first patch were suggested on the review to complement
> the fix.
>
> The changes were run-tested on a Digilent Zybo Z7 board
>
> Luis Araneda (2):
> ARM: zynq: support smp in thumb mode
> ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
>
> arch/arm/mach-zynq/headsmp.S | 2 ++
> arch/arm/mach-zynq/platsmp.c | 4 ++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.22.0
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
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] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-06 5:12 UTC (permalink / raw)
To: Gavin Li
Cc: Gavin Li, Shawn Anastasio, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Will Deacon, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <CA+GxvY5C_rrukCzC5K-h72bePyW8PS_Rfj3uxh-K6UrcAextUQ@mail.gmail.com>
On Mon, Aug 05, 2019 at 07:55:44PM -0700, Gavin Li wrote:
> > /* create a coherent mapping */
> > ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
> > - arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
> > + dma_pgprot(dev, PAGE_KERNEL, attrs),
> > __builtin_return_address(0));
> > if (!ret) {
> > __dma_direct_free_pages(dev, size, page);
>
> Is dma_common_contiguous_remap() still necessary in the
> DMA_ATTR_NON_CONSISTENT case? I would presume it would be fine to just
> return a linearly mapped address in that case.
It would not be required for a real DMA_ATTR_NON_CONSISTENT
implementation. But only parisc and mips actually properly implement
DMA_ATTR_NON_CONSISTENT, everyone ignores it. Given that the API is
a little ill defined and I have a better replacement in the pipeline
I don't want to start implementing it for other architectures now.
_______________________________________________
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 net-next 06/10] net: stmmac: Implement RSS and enable it in XGMAC core
From: Jakub Kicinski @ 2019-08-06 4:46 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <e70981c111ac857a0bac77750bd69a3383d99ee0.1565027782.git.joabreu@synopsys.com>
On Mon, 5 Aug 2019 20:01:19 +0200, Jose Abreu wrote:
> Implement the RSS functionality and add the corresponding callbacks in
> XGMAC core.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> ---
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Jose Abreu <joabreu@synopsys.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> index c4c45402b8f8..9ff9d9ac1a50 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> @@ -254,6 +254,34 @@ static void dwxgmac2_clear(struct dma_desc *p)
> p->des3 = 0;
> }
>
> +static int dwxgmac2_get_rx_hash(struct dma_desc *p, u32 *hash,
> + enum pkt_hash_types *type)
> +{
> + unsigned int rdes3 = le32_to_cpu(p->des3);
> + u32 ptype;
> +
> + if (rdes3 & XGMAC_RDES3_RSV) {
> + ptype = (rdes3 & XGMAC_RDES3_L34T) >> XGMAC_RDES3_L34T_SHIFT;
> +
> + switch (ptype) {
> + case 0x1:
> + case 0x2:
> + case 0x9:
> + case 0xA:
nit: it'd be nice to have defines for these constants
> + *type = PKT_HASH_TYPE_L4;
> + break;
> + default:
> + *type = PKT_HASH_TYPE_L3;
> + break;
> + }
> +
> + *hash = le32_to_cpu(p->des1);
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> const struct stmmac_desc_ops dwxgmac210_desc_ops = {
> .tx_status = dwxgmac2_get_tx_status,
> .rx_status = dwxgmac2_get_rx_status,
> @@ -4182,7 +4208,7 @@ int stmmac_dvr_probe(struct device *device,
> struct net_device *ndev = NULL;
> struct stmmac_priv *priv;
> u32 queue, maxq;
> - int ret = 0;
> + int i, ret = 0;
>
> ndev = devm_alloc_etherdev_mqs(device, sizeof(struct stmmac_priv),
> MTL_MAX_TX_QUEUES, MTL_MAX_RX_QUEUES);
> @@ -4290,6 +4316,14 @@ int stmmac_dvr_probe(struct device *device,
> #endif
> priv->msg_enable = netif_msg_init(debug, default_msg_level);
>
> + /* Initialize RSS */
> + netdev_rss_key_fill(priv->rss.key, sizeof(priv->rss.key));
> + for (i = 0; i < ARRAY_SIZE(priv->rss.table); i++)
> + priv->rss.table[i] = i % priv->plat->rx_queues_to_use;
ethtool_rxfh_indir_default() ?
> + if (priv->dma_cap.rssen && priv->plat->rss_en)
> + ndev->features |= NETIF_F_RXHASH;
> +
> /* MTU range: 46 - hw-specific max */
> ndev->min_mtu = ETH_ZLEN - ETH_HLEN;
> if ((priv->plat->enh_desc) || (priv->synopsys_id >= DWMAC_CORE_4_00))
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
From: Z.q. Hou @ 2019-08-06 4:39 UTC (permalink / raw)
To: Xiaowei Bao, bhelgaas@google.com, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, Leo Li, kishon@ti.com,
lorenzo.pieralisi@arm.com, arnd@arndb.de,
gregkh@linuxfoundation.org, M.h. Lian, Mingkai Hu, Roy Zang,
kstewart@linuxfoundation.org, pombredanne@nexb.com,
shawn.lin@rock-chips.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Cc: Xiaowei Bao
In-Reply-To: <20190805040453.48009-3-xiaowei.bao@nxp.com>
Hi Xiaowei,
> -----Original Message-----
> From: Xiaowei Bao [mailto:xiaowei.bao@nxp.com]
> Sent: 2019年8月5日 12:05
> To: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> Z.q. Hou <zhiqiang.hou@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> kstewart@linuxfoundation.org; pombredanne@nexb.com;
> shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Cc: Xiaowei Bao <xiaowei.bao@nxp.com>
> Subject: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
>
> Add support for the LS1028a PCIe controller.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - no change.
>
> drivers/pci/controller/dwc/pci-layerscape.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> b/drivers/pci/controller/dwc/pci-layerscape.c
> index 3a5fa26..8c556e1 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -236,6 +236,14 @@ static const struct ls_pcie_drvdata ls1043_drvdata =
> {
> .dw_pcie_ops = &dw_ls_pcie_ops,
> };
>
> +static const struct ls_pcie_drvdata ls1028a_drvdata = {
> + .lut_offset = 0x80000,
> + .ltssm_shift = 0,
> + .lut_dbg = 0x407fc,
> + .ops = &ls_pcie_host_ops,
> + .dw_pcie_ops = &dw_ls_pcie_ops,
> +};
> +
Reuse the driver data structure of LS2088 instead add a new one.
- Zhiqiang
> static const struct ls_pcie_drvdata ls1046_drvdata = {
> .lut_offset = 0x80000,
> .ltssm_shift = 24,
> @@ -263,6 +271,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata =
> { static const struct of_device_id ls_pcie_of_match[] = {
> { .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
> { .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> + { .compatible = "fsl,ls1028a-pcie", .data = &ls1028a_drvdata },
> { .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> { .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
> { .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> --
> 2.9.5
_______________________________________________
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 net-next 03/10] net: stmmac: Fix issues when number of Queues >= 4
From: Jakub Kicinski @ 2019-08-06 4:34 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <5e95bb1761f9438361f198d744640685a34790ea.1565027782.git.joabreu@synopsys.com>
On Mon, 5 Aug 2019 20:01:16 +0200, Jose Abreu wrote:
> When queues >= 4 we use different registers but we were not subtracting
> the offset of 4. Fix this.
>
> Found out by Coverity.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Should this be a bug fix for the net tree?
_______________________________________________
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] arm64/cache: fix -Woverride-init compiler warnings
From: Qian Cai @ 2019-08-06 3:50 UTC (permalink / raw)
To: Will Deacon; +Cc: Mark Rutland, Catalin Marinas, linux-kernel, linux-arm-kernel
In-Reply-To: <20190805140118.fys437oor2b2rnq5@willie-the-truck>
> On Aug 5, 2019, at 10:01 AM, Will Deacon <will@kernel.org> wrote:
>
> On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
>>
>>
>>> On Aug 5, 2019, at 5:52 AM, Will Deacon <will@kernel.org> wrote:
>>>
>>> On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
>>>> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
>>>> VIVT I-caches") introduced some compiation warnings from GCC,
>>>>
>>>> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_VIPT] = "VIPT",
>>>> ^~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
>>>> 'icache_policy_str[2]')
>>>> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_PIPT] = "PIPT",
>>>> ^~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
>>>> 'icache_policy_str[3]')
>>>> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>> ^~~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
>>>> 'icache_policy_str[0]')
>>>>
>>>> because it initializes icache_policy_str[0 ... 3] twice.
>>>>
>>>> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
>>>> Signed-off-by: Qian Cai <cai@lca.pw>
>>>> ---
>>>> arch/arm64/kernel/cpuinfo.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>>>> index 876055e37352..193b38da8d96 100644
>>>> --- a/arch/arm64/kernel/cpuinfo.c
>>>> +++ b/arch/arm64/kernel/cpuinfo.c
>>>> @@ -34,10 +34,10 @@
>>>> static struct cpuinfo_arm64 boot_cpu_data;
>>>>
>>>> static char *icache_policy_str[] = {
>>>> - [0 ... ICACHE_POLICY_PIPT] = "RESERVED/UNKNOWN",
>>>> + [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>> + [ICACHE_POLICY_VPIPT + 1] = "RESERVED/UNKNOWN",
>>>> [ICACHE_POLICY_VIPT] = "VIPT",
>>>> [ICACHE_POLICY_PIPT] = "PIPT",
>>>> - [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>
>>> I really don't like this patch. Using "[0 ... MAXIDX] = <default>" is a
>>> useful idiom and I think the code is more error-prone the way you have
>>> restructured it.
>>>
>>> Why are you passing -Woverride-init to the compiler anyway? There's only
>>> one Makefile that references that option, and it's specific to a pinctrl
>>> driver.
>>
>> Those extra warnings can be enabled by “make W=1”. “-Woverride-init “ seems to be useful
>> to catch potential developer mistakes with unintented double-initializations. It is normal to
>> start to fix the most of false-positives first before globally enabling the flag by default just like
>> “-Wimplicit-fallthrough” mentioned in,
>>
>> https://lwn.net/Articles/794944/
>
> I think this case is completely different to the implicit fallthrough stuff.
> The solution there was simply to add a comment without restructuring the
> surrounding code. What your patch does here is actively make the code harder
> to understand.
>
> Initialising a static array with a non-zero pattern is a useful idiom and I
> don't think we should throw that away just to appease a silly compiler
> warning that appears only with non-default build options. Have a look at
> the way we use PERF_MAP_ALL_UNSUPPORTED in the Arm PMU code, for example.
Well, both GCC and Clang would generate warnings for those. Clang even enable this by
default,
https://releases.llvm.org/8.0.0/tools/clang/docs/DiagnosticsReference.html#winitializer-overrides
Assume compiler people are sane, I probably not call those are “silly”.
_______________________________________________
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] pinctrl: spear: spear: Add of_node_put() before return
From: Viresh Kumar @ 2019-08-06 3:42 UTC (permalink / raw)
To: Nishka Dasgupta; +Cc: vireshk, linus.walleij, linux-arm-kernel, linux-gpio
In-Reply-To: <20190804154948.4584-1-nishkadg.linux@gmail.com>
On 04-08-19, 21:19, Nishka Dasgupta wrote:
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return in
> two places.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
> drivers/pinctrl/spear/pinctrl-spear.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
> index c4f850345dc4..7ec19c73f870 100644
> --- a/drivers/pinctrl/spear/pinctrl-spear.c
> +++ b/drivers/pinctrl/spear/pinctrl-spear.c
> @@ -157,12 +157,16 @@ static int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
> /* calculate number of maps required */
> for_each_child_of_node(np_config, np) {
> ret = of_property_read_string(np, "st,function", &function);
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(np);
> return ret;
> + }
>
> ret = of_property_count_strings(np, "st,pins");
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(np);
> return ret;
> + }
>
> count += ret;
> }
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
_______________________________________________
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: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
This fixes a kernel panic (read overflow) on memcpy when
FORTIFY_SOURCE is enabled.
The computed size of memcpy args are:
- p_size (dst): 4294967295 = (size_t) -1
- q_size (src): 1
- size (len): 8
Additionally, the memory is marked as __iomem, so one of
the memcpy_* functions should be used for read/write
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
---
arch/arm/mach-zynq/platsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 38728badabd4..a10085be9073 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -57,7 +57,7 @@ int zynq_cpun_start(u32 address, int cpu)
* 0x4: Jump by mov instruction
* 0x8: Jumping address
*/
- memcpy((__force void *)zero, &zynq_secondary_trampoline,
+ memcpy_toio(zero, &zynq_secondary_trampoline,
trampoline_size);
writel(address, zero + trampoline_size);
--
2.22.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 1/2] ARM: zynq: support smp in thumb mode
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
Add .arm directive to headsmp.S to ensure that the
CPU starts in 32-bit ARM mode and the correct code
size is copied on smp bring-up
Additionally, start secondary CPUs on secondary_startup_arm
to automatically switch from ARM to thumb on a thumb kernel
Suggested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
---
arch/arm/mach-zynq/headsmp.S | 2 ++
arch/arm/mach-zynq/platsmp.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/headsmp.S b/arch/arm/mach-zynq/headsmp.S
index ab85003cf9ad..3449e0d1f990 100644
--- a/arch/arm/mach-zynq/headsmp.S
+++ b/arch/arm/mach-zynq/headsmp.S
@@ -7,6 +7,8 @@
#include <linux/init.h>
#include <asm/assembler.h>
+ .arm
+
ENTRY(zynq_secondary_trampoline)
ARM_BE8(setend be) @ ensure we are in BE8 mode
ldr r0, zynq_secondary_trampoline_jump
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index a7cfe07156f4..38728badabd4 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -81,7 +81,7 @@ EXPORT_SYMBOL(zynq_cpun_start);
static int zynq_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
- return zynq_cpun_start(__pa_symbol(secondary_startup), cpu);
+ return zynq_cpun_start(__pa_symbol(secondary_startup_arm), cpu);
}
/*
--
2.22.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 0/2] ARM: zynq: smp improvements
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
This series adds support for kernel compiled in Thumb mode
and fixes a kernel panic on smp bring-up when FORTIFY_SOURCE
is enabled.
The series started with the second patch as an RFC, and
the first patch were suggested on the review to complement
the fix.
The changes were run-tested on a Digilent Zybo Z7 board
Luis Araneda (2):
ARM: zynq: support smp in thumb mode
ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
arch/arm/mach-zynq/headsmp.S | 2 ++
arch/arm/mach-zynq/platsmp.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.22.0
_______________________________________________
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] arm64/prefetch: fix a -Wtype-limits warning
From: Qian Cai @ 2019-08-06 3:05 UTC (permalink / raw)
To: will, catalin.marinas
Cc: rrichter, Qian Cai, robin.murphy, linux-kernel, linux-arm-kernel
The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
warning from GCC,
In file included from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/linux/cpumask.h:10,
from arch/arm64/kernel/cpufeature.c:11:
arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
^~
arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
'MIDR_IS_CPU_MODEL_RANGE'
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
^~~~~~~~~~~~~~~~~~~~~~~
Fix it by converting MIDR_IS_CPU_MODEL_RANGE to a static inline
function.
Signed-off-by: Qian Cai <cai@lca.pw>
---
v3: Convert MIDR_IS_CPU_MODEL_RANGE to a static inline function.
v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
arch/arm64/include/asm/cputype.h | 21 +++++++++++----------
arch/arm64/kernel/cpufeature.c | 2 +-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index e7d46631cc42..b1454d117cd2 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -51,14 +51,6 @@
#define MIDR_CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
MIDR_ARCHITECTURE_MASK)
-#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
-({ \
- u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
- u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
- \
- _model == (model) && rv >= (rv_min) && rv <= (rv_max); \
- })
-
#define ARM_CPU_IMP_ARM 0x41
#define ARM_CPU_IMP_APM 0x50
#define ARM_CPU_IMP_CAVIUM 0x43
@@ -159,10 +151,19 @@ struct midr_range {
#define MIDR_REV(m, v, r) MIDR_RANGE(m, v, r, v, r)
#define MIDR_ALL_VERSIONS(m) MIDR_RANGE(m, 0, 0, 0xf, 0xf)
+static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min,
+ u32 rv_max)
+{
+ u32 _model = midr & MIDR_CPU_MODEL_MASK;
+ u32 rv = midr & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK);
+
+ return _model == model && rv >= rv_min && rv <= rv_max;
+}
+
static inline bool is_midr_in_range(u32 midr, struct midr_range const *range)
{
- return MIDR_IS_CPU_MODEL_RANGE(midr, range->model,
- range->rv_min, range->rv_max);
+ return midr_is_cpu_model_range(midr, range->model,
+ range->rv_min, range->rv_max);
}
static inline bool
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d19d14ba9ae4..95201e5ff5e1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -886,7 +886,7 @@ static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry, int _
u32 midr = read_cpuid_id();
/* Cavium ThunderX pass 1.x and 2.x */
- return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
+ return midr_is_cpu_model_range(midr, MIDR_THUNDERX,
MIDR_CPU_VAR_REV(0, 0),
MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
}
--
2.20.1 (Apple Git-117)
_______________________________________________
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 v2] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Hui Song @ 2019-08-06 2:49 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..2df5fc0 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -37,3 +37,17 @@ gpio0: gpio@2300000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+
+Example of gpio-controller node for a ls1028a SoC:
+
+gpio1: gpio@2300000 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+};
--
2.9.5
_______________________________________________
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 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Gavin Li @ 2019-08-06 2:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Shawn Anastasio, Will Deacon, Michael Ellerman,
linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Robin Murphy, linux-arm-kernel
In-Reply-To: <CAP_+7SzPdNCMKuuXMjHjpCzxsey2YWR_e6mTAWtNSZ6kKBvKFw@mail.gmail.com>
> /* create a coherent mapping */
> ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
> - arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
> + dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0));
> if (!ret) {
> __dma_direct_free_pages(dev, size, page);
Is dma_common_contiguous_remap() still necessary in the
DMA_ATTR_NON_CONSISTENT case? I would presume it would be fine to just
return a linearly mapped address in that case.
_______________________________________________
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] clk: imx: disable i.mx7ulp composite clock during initialization
From: Anson Huang @ 2019-08-06 2:25 UTC (permalink / raw)
To: Stephen Boyd, festevam@gmail.com, gustavo@embeddedor.com,
kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
mturquette@baylibre.com, s.hauer@pengutronix.de,
shawnguo@kernel.org, Aisheng Dong
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB39165F69F8B684D323C683B1F5C60@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi, Stephen
I think we should resume this thread, without this patch, mainline kernel boot up will cause mmc timeout all the time. If it is NOT good to disabling those peripheral devices' clock in i.MX7ULP's clock driver, then we have to change the core framework to disable clock explicitly if the CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE is present, most likely it will impact other platforms I think, so the most safe way is just to do it inside our i.MX7ULP composite clock driver. What do you think?
Thanks,
Anson
> Hi, Stephen
>
> > Quoting Anson Huang (2019-04-24 22:19:12)
> > > i.MX7ULP peripheral clock ONLY allow parent/rate to be changed with
> > > clock gated, however, during clock tree initialization, the
> > > peripheral clock could be enabled by bootloader, but the prepare
> > > count in clock tree is still zero, so clock core driver will allow
> > > parent/rate changed even with
> CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE
> >
> > That's a bug. Can you send a patch to fix the core framework code to
> > fail an assigned rate or parent change if those flags are set? Or is
> > that because the core doesn't respect these flags when they're buried
> > in the middle of the clk tree and some rate or parent change comes in
> > and affects the middle of the tree that has the flag set on it?
>
> If changing the core framework code to return fail for clk parent/rate
> assignment, that means clk assignment in DT will NOT work for i.MX7ULP,
> then all the clk rate/parent settings will be done in driver? That will lead to
> more issues/changes.
>
> It is just because core framework ONLY checks the prepare_count and
> CLK_SET_PARENT_GATE flag to determine if the parent switch is allowed,
> however, during clock tree initialization, the prepare_count is always 0 but
> the HW status could be enabled actually, so the core framework will allow
> the parent switch while HW status does NOT allow the parent switch, so core
> framework will treat the parent switch successfully but HW is actually NOT.
>
> I think we can treat it as platform specific issue, if bootloader can guarantee
> all peripheral clocks are disabled before jumping to kernel, then there will be
> no issue, but we can NOT assume that, so I have to find some place in early
> kernel phase to disable those peripheral clocks.
>
> >
> > > set, but the change will fail due to HW NOT allow parent/rate change
> > > with clock enabled. It will cause clock HW status mismatch with
> > > clock tree info and lead to function issue. Below is an example:
> > >
> > > usdhc0's pcc clock value is 0xC5000000 during kernel boot up, it
> > > means
> > > usdhc0 clock is enabled, its parent is APLL_PFD1. In DT file, the
> > > usdhc0 clock settings are as below:
> > >
> > > assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC0>; assigned-clock-parents
> > > =
> > > <&scg1 IMX7ULP_CLK_NIC1_DIV>;
> > >
> > > when kernel boot up, the clock tree info is as below, but the usdhc0
> > > PCC register is still 0xC5000000, which means its parent is still
> > > from APLL_PFD1, which is incorrect and cause usdhc0 NOT work.
> > >
> > > nic1_clk 2 2 0 176000000 0 0 50000
> > > usdhc0 0 0 0 176000000 0 0 50000
> > >
> > > After making sure the peripheral clock is disabled during clock tree
> > > initialization, the usdhc0 is working, and this change is necessary
> > > for all i.MX7ULP peripheral clocks.
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > drivers/clk/imx/clk-composite-7ulp.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/clk/imx/clk-composite-7ulp.c
> > > b/drivers/clk/imx/clk-composite-7ulp.c
> > > index 060f860..1a05411 100644
> > > --- a/drivers/clk/imx/clk-composite-7ulp.c
> > > +++ b/drivers/clk/imx/clk-composite-7ulp.c
> > > @@ -32,6 +32,7 @@ struct clk_hw *imx7ulp_clk_composite(const char
> > *name,
> > > struct clk_gate *gate = NULL;
> > > struct clk_mux *mux = NULL;
> > > struct clk_hw *hw;
> > > + u32 val;
> > >
> > > if (mux_present) {
> > > mux = kzalloc(sizeof(*mux), GFP_KERNEL); @@ -70,6
> > > +71,18 @@ struct clk_hw *imx7ulp_clk_composite(const char *name,
> > > gate_hw = &gate->hw;
> > > gate->reg = reg;
> > > gate->bit_idx = PCG_CGC_SHIFT;
> > > + /*
> > > + * make sure clock is gated during clock tree initialization,
> > > + * the HW ONLY allow clock parent/rate changed with clock
> gated,
> > > + * during clock tree initialization, clocks could be enabled
> > > + * by bootloader, so the HW status will mismatch with clock tree
> > > + * prepare count, then clock core driver will allow parent/rate
> > > + * change since the prepare count is zero, but HW actually
> > > + * prevent the parent/rate change due to the clock is enabled.
> > > + */
> >
> > Is it OK to forcibly gate the clk like this at init time? If so, why
> > can't we force the clk off when we change the rate and then restore
> > the on state after changing the rate? That would be more "robust" than
> > doing it once here. Plus then we could remove the CLK_SET_RATE_GATE
> flag.
>
> Yes, it is ONLY for composite clocks which are for peripheral clocks, ONLY
> earlycon could be impacted but we can add imx_register_uart_clocks() call to
> make earlycon also work.
>
> Forcing the clk off and restore them ON for rate/parent change will need to
> change common composite clock ops, currently i.MX7ULP all use common
> ops, so unless i.MX7ULP implements composite clock ops, and the change
> will be very significant.
>
> Thanks,
> Anson
>
> >
> > > + val = readl_relaxed(reg);
> > > + val &= ~(1 << PCG_CGC_SHIFT);
> > > + writel_relaxed(val, reg);
> > > }
> > >
_______________________________________________
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] clocksource: imx-sysctr: Add internal clock divider handle
From: Anson Huang @ 2019-08-06 1:55 UTC (permalink / raw)
To: catalin.marinas@arm.com, will@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
daniel.lezcano@linaro.org, tglx@linutronix.de, Leonard Crestez,
Aisheng Dong, Daniel Baluta, Jacky Bai, l.stach@pengutronix.de,
Abel Vesa, andrew.smirnov@gmail.com, ccaione@baylibre.com,
angus@akkea.ca, agx@sigxcpu.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <20190710063056.35689-1-Anson.Huang@nxp.com>
Gentle ping...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> The system counter block guide states that the base clock is internally divided
> by 3 before use, that means the clock input of system counter defined in DT
> should be base clock which is normally from OSC, and then internally divided
> by 3 before use.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V4:
> - to solve the clock driver probed after system counter driver issue,
> now we can easily switch to
> use fixed clock defined in DT and get its rate, then divided by 3 to
> get real clock rate for
> system counter driver, no need to add "clock-frequency" property in
> DT.
> ---
> drivers/clocksource/timer-imx-sysctr.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/clocksource/timer-imx-sysctr.c
> b/drivers/clocksource/timer-imx-sysctr.c
> index fd7d680..b7c80a3 100644
> --- a/drivers/clocksource/timer-imx-sysctr.c
> +++ b/drivers/clocksource/timer-imx-sysctr.c
> @@ -20,6 +20,8 @@
> #define SYS_CTR_EN 0x1
> #define SYS_CTR_IRQ_MASK 0x2
>
> +#define SYS_CTR_CLK_DIV 0x3
> +
> static void __iomem *sys_ctr_base;
> static u32 cmpcr;
>
> @@ -134,6 +136,9 @@ static int __init sysctr_timer_init(struct device_node
> *np)
> if (ret)
> return ret;
>
> + /* system counter clock is divided by 3 internally */
> + to_sysctr.of_clk.rate /= SYS_CTR_CLK_DIV;
> +
> sys_ctr_base = timer_of_base(&to_sysctr);
> cmpcr = readl(sys_ctr_base + CMPCR);
> cmpcr &= ~SYS_CTR_EN;
> --
> 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: [RFC PATCH] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Luis Araneda @ 2019-08-06 1:52 UTC (permalink / raw)
To: Michal Simek
Cc: Russell King - ARM Linux admin, linux-arm-kernel, linux-kernel
In-Reply-To: <26427757-9ed1-36fa-3e4d-7357703ec548@xilinx.com>
Hi Michal,
Thanks for the review.
On Mon, Aug 5, 2019 at 5:53 AM Michal Simek <michal.simek@xilinx.com> wrote:
>
> On 31. 07. 19 6:12, Luis Araneda wrote:
> > Hi Russell,
> >
> > Thanks for reviewing.
> >
> > On Tue, Jul 30, 2019 at 6:47 AM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> >>
> >> On Tue, Jul 30, 2019 at 12:43:26AM -0400, Luis Araneda wrote:
> >>> This fixes a kernel panic (read overflow) on memcpy when
> >>> FORTIFY_SOURCE is enabled.
> > [...]
> >>
> >> I'm not convinced that this is correct. It looks like
> >> zynq_secondary_trampoline could be either ARM or Thumb code - there is
> >> no .arm directive before it. If it's ARM code, then this is fine. If
> >> Thumb code, then zynq_secondary_trampoline will be offset by one, and
> >> we will miss copying the first byte of code.
> >
> > You're right, I tested what happens if the zynq_secondary_trampoline
> > is ARM or Thumb by editing the file where it's defined, headsmp.S
> >
> > When the .arm directive is used, the CPU is brought-up correctly,
> > but if I use .thumb, I get the following message (no panic):
> >> CPU1: failed to come online
> >
> > This seems unrelated to solving the panic, as the message
> > even appears with memcpy and FORTIFY_SOURCE disabled.
> >
> > I could add the .arm directive to headsmp.S
> > Is that your expected solution?
> > Should that change be on a separate commit?
> >
> > I'd like to know Michal's opinion, as he wrote the code.
> >
>
> There are two things together. Thanks Russel to pointing to it.
> 1. How to support SMP in thumb2 mode?
> Adding .arm mode to headsmp.S which ensure that cpu starts in proper
> mode and correct code size is copied.
> And also point to secondary_startup_arm in zynq_boot_secondary to switch
> cpu from arm to thumb mode.
>
> 2. And the second is this patch to fix FORTIFY_SOURCE.
>
> Feel free to create the first patch too or I will do it myself.
I'll be sending the two patches as a series (I already tested that
they work), so they can be picked by the stable trees.
Thanks,
Luis Araneda.
_______________________________________________
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