* Fw:Hallöchen. alles gut bei dir?
From: nik_bin_nek_alwi @ 2019-08-22 11:46 UTC (permalink / raw)
To: rob herring, hsweeten, buildroot, linux arm kernel, Paul Chavent,
Arnd Bergmann, Sascha Hauer, Olof Johansson
Einfach super! http://watchsunpena1970.blogspot.nl/
___
Mit ganz lieben Grüßen
nik_bin_nek_alwi@yahoo.com
_______________________________________________
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 4/9] powerpc: numa: check the node id consistently for powerpc
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
This patch checks node id with the below case before returning
node_to_cpumask_map[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/powerpc/include/asm/topology.h | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 2f7e1ea..217dc9b 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -17,9 +17,16 @@ struct device_node;
#include <asm/mmzone.h>
-#define cpumask_of_node(node) ((node) == -1 ? \
- cpu_all_mask : \
- node_to_cpumask_map[node])
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
+
+ return node_to_cpumask_map[node];
+}
struct pci_bus;
#ifdef CONFIG_PCI
--
2.8.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 v2 6/9] sh: numa: check the node id consistently for sh
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
It seems sh does not have real numa support or uncompleted
numa support, this patch still checks node id with the below
case to ensure future support is consistent:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/sh/include/asm/topology.h | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/topology.h b/arch/sh/include/asm/topology.h
index 1db470e..e71e0a0 100644
--- a/arch/sh/include/asm/topology.h
+++ b/arch/sh/include/asm/topology.h
@@ -6,7 +6,19 @@
#define cpu_to_node(cpu) ((void)(cpu),0)
-#define cpumask_of_node(node) ((void)node, cpu_online_mask)
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
+
+ /* Should return actual mask based on node_to_cpumask_map
+ * if sh arch supports real numa node.
+ */
+ return cpu_online_mask;
+}
#define pcibus_to_node(bus) ((void)(bus), -1)
#define cpumask_of_pcibus(bus) (pcibus_to_node(bus) == -1 ? \
--
2.8.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 v2 8/9] mips: numa: check the node id consistently for mips ip27
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
Since mips ip27 uses hub_data instead of node_to_cpumask_map,
this patch checks node id with the below case before returning
&hub_data(node)->h_cpus:
1. if node_id >= MAX_COMPACT_NODES, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if hub_data(node) is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/mips/include/asm/mach-ip27/topology.h | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/mips/include/asm/mach-ip27/topology.h b/arch/mips/include/asm/mach-ip27/topology.h
index 965f079..914a55a 100644
--- a/arch/mips/include/asm/mach-ip27/topology.h
+++ b/arch/mips/include/asm/mach-ip27/topology.h
@@ -15,9 +15,18 @@ struct cpuinfo_ip27 {
extern struct cpuinfo_ip27 sn_cpu_info[NR_CPUS];
#define cpu_to_node(cpu) (sn_cpu_info[(cpu)].p_nodeid)
-#define cpumask_of_node(node) ((node) == -1 ? \
- cpu_all_mask : \
- &hub_data(node)->h_cpus)
+
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ if (node >= MAX_COMPACT_NODES)
+ return cpu_none_mask;
+
+ if (node < 0 || !hub_data(node))
+ return cpu_online_mask;
+
+ return &hub_data(node)->h_cpus;
+}
+
struct pci_bus;
extern int pcibus_to_node(struct pci_bus *);
--
2.8.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 v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
This patch checks node id with the below case before returning
&numa_cpumask_lookup_table[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. Since numa_cpumask_lookup_table is not a pointer, a comment
is added to indicate that
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/sparc/include/asm/topology_64.h | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/include/asm/topology_64.h b/arch/sparc/include/asm/topology_64.h
index 34c628a..66a7917 100644
--- a/arch/sparc/include/asm/topology_64.h
+++ b/arch/sparc/include/asm/topology_64.h
@@ -11,9 +11,19 @@ static inline int cpu_to_node(int cpu)
return numa_cpu_lookup_table[cpu];
}
-#define cpumask_of_node(node) ((node) == -1 ? \
- cpu_all_mask : \
- &numa_cpumask_lookup_table[node])
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ if (node >= MAX_NUMNODES)
+ return cpu_none_mask;
+
+ /* numa_cpumask_lookup_table[node] is not a pointer, so
+ * no need to check for NULL here.
+ */
+ if (node < 0)
+ return cpu_online_mask;
+
+ return &numa_cpumask_lookup_table[node];
+}
struct pci_bus;
#ifdef CONFIG_PCI
--
2.8.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 v2 9/9] mips: numa: check the node id consistently for mips loongson64
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
Since mips loongson64 uses __node_data instead of
node_to_cpumask_map, this patch checks node id with the below
case before returning &__node_data[node]->cpumask:
1. if node_id >= MAX_NUMNODES, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if hub_data(node) is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/mips/include/asm/mach-loongson64/topology.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/mach-loongson64/topology.h b/arch/mips/include/asm/mach-loongson64/topology.h
index 7ff819a..b19b983 100644
--- a/arch/mips/include/asm/mach-loongson64/topology.h
+++ b/arch/mips/include/asm/mach-loongson64/topology.h
@@ -5,7 +5,17 @@
#ifdef CONFIG_NUMA
#define cpu_to_node(cpu) (cpu_logical_map(cpu) >> 2)
-#define cpumask_of_node(node) (&__node_data[(node)]->cpumask)
+
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+ if (node >= MAX_NUMNODES)
+ return cpu_none_mask;
+
+ if (node < 0 || !__node_data[node])
+ return cpu_online_mask;
+
+ return &__node_data[node]->cpumask;
+}
struct pci_bus;
extern int pcibus_to_node(struct pci_bus *);
--
2.8.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 v2 3/9] alpha: numa: check the node id consistently for alpha
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
This patch checks node id with the below case before returning
node_to_cpumask_map[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
note node_to_cpumask_map[node] is already a pointer, so the
cpumask_clear should be called with node_to_cpumask_map[node]
instead of &node_to_cpumask_map[node]? And cpumask_of_node()
function need to be inlined when defined in a header file?
If the above are problems, maybe another patch to fix or clean
it up.
---
arch/alpha/include/asm/topology.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/include/asm/topology.h b/arch/alpha/include/asm/topology.h
index 5a77a40..9e0b1cd1 100644
--- a/arch/alpha/include/asm/topology.h
+++ b/arch/alpha/include/asm/topology.h
@@ -30,8 +30,11 @@ static const struct cpumask *cpumask_of_node(int node)
{
int cpu;
- if (node == NUMA_NO_NODE)
- return cpu_all_mask;
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
cpumask_clear(&node_to_cpumask_map[node]);
--
2.8.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 v2 5/9] s390: numa: check the node id consistently for s390
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
This patch checks node id with the below case before returning
node_to_cpumask_map[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
Note node_to_cpumask_map[node] is already a pointer, so
returning &node_to_cpumask_map[node] does not seem to
be correct, if this is problem, maybe clean it up in another
patch.
---
arch/s390/include/asm/topology.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index cca406f..75340ca 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -78,6 +78,12 @@ static inline int cpu_to_node(int cpu)
#define cpumask_of_node cpumask_of_node
static inline const struct cpumask *cpumask_of_node(int node)
{
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
+
return &node_to_cpumask_map[node];
}
--
2.8.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 v2 1/9] arm64: numa: check the node id consistently for arm64
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
When enabling KASAN and bios has not implemented the proximity
domain of the hns3 device, there is a global-out-of-bounds error
below:
[ 42.970381] ==================================================================
[ 42.977595] BUG: KASAN: global-out-of-bounds in __bitmap_weight+0x48/0xb0
[ 42.984370] Read of size 8 at addr ffff20008cdf8790 by task kworker/0:1/13
[ 42.991230]
[ 42.992712] CPU: 0 PID: 13 Comm: kworker/0:1 Tainted: G O 5.2.0-rc4-g8bde06a-dirty #3
[ 43.001830] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B050.01 08/08/2019
[ 43.011298] Workqueue: events work_for_cpu_fn
[ 43.015643] Call trace:
[ 43.018078] dump_backtrace+0x0/0x1e8
[ 43.021727] show_stack+0x14/0x20
[ 43.025031] dump_stack+0xc4/0xfc
[ 43.028335] print_address_description+0x178/0x270
[ 43.033113] __kasan_report+0x164/0x1b8
[ 43.036936] kasan_report+0xc/0x18
[ 43.040325] __asan_load8+0x84/0xa8
[ 43.043801] __bitmap_weight+0x48/0xb0
[ 43.047552] hclge_init_ae_dev+0x988/0x1e78 [hclge]
[ 43.052418] hnae3_register_ae_dev+0xcc/0x278 [hnae3]
[ 43.057467] hns3_probe+0xe0/0x120 [hns3]
[ 43.061464] local_pci_probe+0x74/0xf0
[ 43.065200] work_for_cpu_fn+0x2c/0x48
[ 43.068937] process_one_work+0x3c0/0x878
[ 43.072934] worker_thread+0x400/0x670
[ 43.076670] kthread+0x1b0/0x1b8
[ 43.079885] ret_from_fork+0x10/0x18
[ 43.083446]
[ 43.084925] The buggy address belongs to the variable:
[ 43.090052] numa_distance+0x30/0x40
[ 43.093613]
[ 43.095091] Memory state around the buggy address:
[ 43.099870] ffff20008cdf8680: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 fa fa
[ 43.107078] ffff20008cdf8700: fa fa fa fa 04 fa fa fa fa fa fa fa 00 fa fa fa
[ 43.114286] >ffff20008cdf8780: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
[ 43.121494] ^
[ 43.125230] ffff20008cdf8800: 01 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[ 43.132439] ffff20008cdf8880: fa fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[ 43.139646] ==================================================================
This patch checks node id with the below case before returning
node_to_cpumask_map[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/arm64/include/asm/numa.h | 6 ++++++
arch/arm64/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 626ad01..65a0ef6 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
static inline const struct cpumask *cpumask_of_node(int node)
{
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
+
return node_to_cpumask_map[node];
}
#endif
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4f241cc..7eca267 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -49,7 +49,7 @@ const struct cpumask *cpumask_of_node(int node)
if (WARN_ON(node >= nr_node_ids))
return cpu_none_mask;
- if (WARN_ON(node_to_cpumask_map[node] == NULL))
+ if (WARN_ON(node < 0 || !node_to_cpumask_map[node]))
return cpu_online_mask;
return node_to_cpumask_map[node];
--
2.8.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 v2 2/9] x86: numa: check the node id consistently for x86
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
In-Reply-To: <1567231103-13237-1-git-send-email-linyunsheng@huawei.com>
According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
This patch checks node id with the below case before returning
node_to_cpumask_map[node]:
1. if node_id >= nr_node_ids, return cpu_none_mask
2. if node_id < 0, return cpu_online_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
arch/x86/include/asm/topology.h | 6 ++++++
arch/x86/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 4b14d23..f36e9c8 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -69,6 +69,12 @@ extern const struct cpumask *cpumask_of_node(int node);
/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
static inline const struct cpumask *cpumask_of_node(int node)
{
+ if (node >= nr_node_ids)
+ return cpu_none_mask;
+
+ if (node < 0 || !node_to_cpumask_map[node])
+ return cpu_online_mask;
+
return node_to_cpumask_map[node];
}
#endif
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index e6dad60..5e393d2 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -868,7 +868,7 @@ const struct cpumask *cpumask_of_node(int node)
dump_stack();
return cpu_none_mask;
}
- if (node_to_cpumask_map[node] == NULL) {
+ if (node < 0 || !node_to_cpumask_map[node]) {
printk(KERN_WARNING
"cpumask_of_node(%d): no node_to_cpumask_map!\n",
node);
--
2.8.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 v2 0/9] check the node id consistently across different arches
From: Yunsheng Lin @ 2019-08-31 5:58 UTC (permalink / raw)
To: catalin.marinas, will, mingo, bp, rth, ink, mattst88, benh,
paulus, mpe, heiko.carstens, gor, borntraeger, ysato, dalias,
davem, ralf, paul.burton, jhogan, jiaxun.yang, chenhc
Cc: linux-sh, peterz, dave.hansen, linuxarm, linux-mips, mwb, hpa,
sparclinux, linux-s390, x86, rppt, dledford, jeffrey.t.kirsher,
nfont, naveen.n.rao, len.brown, anshuman.khandual, cai, luto,
tglx, linux-arm-kernel, axboe, robin.murphy, linux-kernel,
tbogendoerfer, linux-alpha, akpm, linuxppc-dev
According to Section 6.2.14 from ACPI spec 6.3 [1], the
setting of proximity domain is optional, as below:
This optional object is used to describe proximity domain
associations within a machine. _PXM evaluates to an integer
that identifies a device as belonging to a Proximity Domain
defined in the System Resource Affinity Table (SRAT).
When enabling KASAN and bios has not implemented the proximity
domain of the hns3 device, there is a global-out-of-bounds error
below:
[ 42.970381] ==================================================================
[ 42.977595] BUG: KASAN: global-out-of-bounds in __bitmap_weight+0x48/0xb0
[ 42.984370] Read of size 8 at addr ffff20008cdf8790 by task kworker/0:1/13
[ 42.991230]
[ 42.992712] CPU: 0 PID: 13 Comm: kworker/0:1 Tainted: G O 5.2.0-rc4-g8bde06a-dirty #3
[ 43.001830] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B050.01 08/08/2019
[ 43.011298] Workqueue: events work_for_cpu_fn
[ 43.015643] Call trace:
[ 43.018078] dump_backtrace+0x0/0x1e8
[ 43.021727] show_stack+0x14/0x20
[ 43.025031] dump_stack+0xc4/0xfc
[ 43.028335] print_address_description+0x178/0x270
[ 43.033113] __kasan_report+0x164/0x1b8
[ 43.036936] kasan_report+0xc/0x18
[ 43.040325] __asan_load8+0x84/0xa8
[ 43.043801] __bitmap_weight+0x48/0xb0
[ 43.047552] hclge_init_ae_dev+0x988/0x1e78 [hclge]
[ 43.052418] hnae3_register_ae_dev+0xcc/0x278 [hnae3]
[ 43.057467] hns3_probe+0xe0/0x120 [hns3]
[ 43.061464] local_pci_probe+0x74/0xf0
[ 43.065200] work_for_cpu_fn+0x2c/0x48
[ 43.068937] process_one_work+0x3c0/0x878
[ 43.072934] worker_thread+0x400/0x670
[ 43.076670] kthread+0x1b0/0x1b8
[ 43.079885] ret_from_fork+0x10/0x18
[ 43.083446]
[ 43.084925] The buggy address belongs to the variable:
[ 43.090052] numa_distance+0x30/0x40
[ 43.093613]
[ 43.095091] Memory state around the buggy address:
[ 43.099870] ffff20008cdf8680: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 fa fa
[ 43.107078] ffff20008cdf8700: fa fa fa fa 04 fa fa fa fa fa fa fa 00 fa fa fa
[ 43.114286] >ffff20008cdf8780: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
[ 43.121494] ^
[ 43.125230] ffff20008cdf8800: 01 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[ 43.132439] ffff20008cdf8880: fa fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[ 43.139646] ==================================================================
As suggested [2] by Michal Hocko:
"if the specification really allows to provide NUMA_NO_NODE (-1) then
the code really has to be prepared for that. And ideally all arches
should deal with that."
This patchset checks the node id with the below case consistently
across different arches in order to be compliant with spec and
backward compatible as much as possible:
1. if node_id < 0, return cpu_online_mask
2. if node_id >= nr_node_ids, return cpu_none_mask
3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
Note:
1. Only arm64 has been compile tested and tested on real board.
2. x86 has been compile tested with defconfig.
3. Other arch has not been compile tested or tested on real board.
Changelog:
V2: Change commit log as suggested by Michal Hocko, and make the change to
other arches as well.
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
[2] https://patchwork.kernel.org/patch/11122823/
Yunsheng Lin (9):
arm64: numa: check the node id consistently for arm64
x86: numa: check the node id consistently for x86
alpha: numa: check the node id consistently for alpha
powerpc: numa: check the node id consistently for powerpc
s390: numa: check the node id consistently for s390
sh: numa: check the node id consistently for sh
sparc64: numa: check the node id consistently for sparc64
mips: numa: check the node id consistently for mips ip27
mips: numa: check the node id consistently for mips loongson64
arch/alpha/include/asm/topology.h | 7 +++++--
arch/arm64/include/asm/numa.h | 6 ++++++
arch/arm64/mm/numa.c | 2 +-
arch/mips/include/asm/mach-ip27/topology.h | 15 ++++++++++++---
arch/mips/include/asm/mach-loongson64/topology.h | 12 +++++++++++-
arch/powerpc/include/asm/topology.h | 13 ++++++++++---
arch/s390/include/asm/topology.h | 6 ++++++
arch/sh/include/asm/topology.h | 14 +++++++++++++-
arch/sparc/include/asm/topology_64.h | 16 +++++++++++++---
arch/x86/include/asm/topology.h | 6 ++++++
arch/x86/mm/numa.c | 2 +-
11 files changed, 84 insertions(+), 15 deletions(-)
--
2.8.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 v2] ARM: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer
From: Nathan Chancellor @ 2019-08-31 6:05 UTC (permalink / raw)
To: Russell King
Cc: Arnd Bergmann, Nick Desaulniers, linux-kernel, Stefan Agner,
clang-built-linux, Matthias Kaehlcke, Nathan Chancellor,
linux-arm-kernel
In-Reply-To: <20190829062635.45609-1-natechancellor@gmail.com>
Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:
arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow
clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot with '-pg' because the
calling convention was not correct. Always build with '-meabi gnu'
when using clang but ensure that '-pg' (which is added with
CONFIG_FUNCTION_TRACER and its prereq CONFIG_HAVE_FUNCTION_TRACER)
cannot be added with it unless this is fixed (which means using
clang 10.0.0 and newer).
Link: https://github.com/ClangBuiltLinux/linux/issues/35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add Nick and Stefan's reviewed by tags
* Move version check from Makefile to Kconfig. This prevents '-pg` from
ever being added if '-meabi gnu' would produce a non-booting kernel
and it allows clang 9.0.0 and earlier to build and link all*config
kernels because the function tracer can't be selected.
arch/arm/Kconfig | 2 +-
arch/arm/Makefile | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a98c7af50bf0..440ad41e77e4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -83,7 +83,7 @@ config ARM
select HAVE_FAST_GUP if ARM_LPAE
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
- select HAVE_FUNCTION_TRACER if !XIP_KERNEL
+ select HAVE_FUNCTION_TRACER if !XIP_KERNEL && (CC_IS_GCC || CLANG_VERSION >= 100000)
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)
select HAVE_IDE if PCI || ISA || PCMCIA
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index a43fc753aa53..aa7023db66c7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -115,6 +115,10 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
CFLAGS_ABI +=-funwind-tables
endif
+ifeq ($(CONFIG_CC_IS_CLANG),y)
+CFLAGS_ABI += -meabi gnu
+endif
+
# Accept old syntax despite ".syntax unified"
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
--
2.23.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 v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: David Miller @ 2019-08-31 6:53 UTC (permalink / raw)
To: linyunsheng
Cc: dalias, linux-sh, peterz, catalin.marinas, dave.hansen,
heiko.carstens, linuxarm, jiaxun.yang, linux-mips, mwb, paulus,
hpa, sparclinux, chenhc, will, cai, linux-s390, ysato, mpe, x86,
rppt, borntraeger, dledford, mingo, jeffrey.t.kirsher, benh,
jhogan, nfont, mattst88, len.brown, gor, anshuman.khandual, bp,
luto, tglx, naveen.n.rao, linux-arm-kernel, rth, axboe,
linuxppc-dev, linux-kernel, ralf, tbogendoerfer, paul.burton,
linux-alpha, ink, akpm, robin.murphy
In-Reply-To: <1567231103-13237-8-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Sat, 31 Aug 2019 13:58:21 +0800
> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> of proximity domain is optional, as below:
What in the world does the ACPI spec have to do with sparc64 NUMA
node ID checking?
_______________________________________________
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: ARM_ERRATA_775420: Spelling s/date/data/
From: Simon Horman @ 2019-08-31 7:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Catalin Marinas, Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <20190828133151.20585-1-geert+renesas@glider.be>
On Wed, Aug 28, 2019 at 03:31:51PM +0200, Geert Uytterhoeven wrote:
> Caching dates is never a good idea ;-)
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index dcf46f0e45c24a5f..eb18279a63027c08 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1040,7 +1040,7 @@ config ARM_ERRATA_775420
> depends on CPU_V7
> help
> This option enables the workaround for the 775420 Cortex-A9 (r2p2,
> - r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance
> + r2p6,r2p8,r2p10,r3p0) erratum. In case a data cache maintenance
> operation aborts with MMU exception, it might cause the processor
> to deadlock. This workaround puts DSB before executing ISB if
> an abort may occur on cache maintenance.
> --
> 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
* [PATCH v2] drm/mcde: Fix DSI transfers
From: Linus Walleij @ 2019-08-31 7:50 UTC (permalink / raw)
To: dri-devel, Maarten Lankhorst, Maxime Ripard, Sean Paul
Cc: Linus Walleij, Stephan Gerhold, linux-arm-kernel,
kbuild test robot
There were bugs in the DSI transfer (read and write) function
as it was only tested with displays ever needing a single byte
to be written. Fixed it up and tested so we can now write
messages of up to 16 bytes and read up to 4 bytes from the
display.
Tested with a Sony ACX424AKP display: this display now self-
identifies and can control backlight in command mode.
Cc: Stephan Gerhold <stephan@gerhold.net>
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Fix a print modifier for dev_err() found by the build robot.
---
drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++++++++++++++++++++++-----------
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 07f7090d08b3..90659d190d78 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
const u32 loop_delay_us = 10; /* us */
const u8 *tx = msg->tx_buf;
u32 loop_counter;
- size_t txlen;
+ size_t txlen = msg->tx_len;
+ size_t rxlen = msg->rx_len;
u32 val;
int ret;
int i;
- txlen = msg->tx_len;
- if (txlen > 12) {
+ if (txlen > 16) {
dev_err(d->dev,
- "dunno how to write more than 12 bytes yet\n");
+ "dunno how to write more than 16 bytes yet\n");
+ return -EIO;
+ }
+ if (rxlen > 4) {
+ dev_err(d->dev,
+ "dunno how to read more than 4 bytes yet\n");
return -EIO;
}
dev_dbg(d->dev,
- "message to channel %d, %zd bytes",
- msg->channel,
- txlen);
+ "message to channel %d, write %zd bytes read %zd bytes\n",
+ msg->channel, txlen, rxlen);
/* Command "nature" */
if (MCDE_DSI_HOST_IS_READ(msg->type))
@@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (mipi_dsi_packet_format_is_long(msg->type))
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
- /* Add one to the length for the MIPI DCS command */
- val |= txlen
- << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
+ val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
@@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
writel(1, d->regs + DSI_DIRECT_CMD_SEND);
loop_counter = 1000 * 1000 / loop_delay_us;
- while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
- DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
- && --loop_counter)
- usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
-
- if (!loop_counter) {
- dev_err(d->dev, "DSI write timeout!\n");
- return -ETIME;
+ if (MCDE_DSI_HOST_IS_READ(msg->type)) {
+ /* Read command */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ (DSI_DIRECT_CMD_STS_READ_COMPLETED |
+ DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
+ } else {
+ /* Writing only */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
}
val = readl(d->regs + DSI_DIRECT_CMD_STS);
+ if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
+ dev_err(d->dev, "read completed with error\n");
+ writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
+ return -EIO;
+ }
if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
dev_err(d->dev, "error during transmission: %04x\n",
@@ -269,10 +290,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (!MCDE_DSI_HOST_IS_READ(msg->type)) {
/* Return number of bytes written */
- if (mipi_dsi_packet_format_is_long(msg->type))
- ret = 4 + txlen;
- else
- ret = 4;
+ ret = txlen;
} else {
/* OK this is a read command, get the response */
u32 rdsz;
@@ -282,7 +300,13 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
rdsz = readl(d->regs + DSI_DIRECT_CMD_RD_PROPERTY);
rdsz &= DSI_DIRECT_CMD_RD_PROPERTY_RD_SIZE_MASK;
rddat = readl(d->regs + DSI_DIRECT_CMD_RDDAT);
- for (i = 0; i < 4 && i < rdsz; i++)
+ if (rdsz < rxlen) {
+ dev_err(d->dev, "read error, requested %zd got %d\n",
+ msg->rx_len, rdsz);
+ return -EIO;
+ }
+ /* FIXME: read more than 4 bytes */
+ for (i = 0; i < 4 && i < rxlen; i++)
rx[i] = (rddat >> (i * 8)) & 0xff;
ret = rdsz;
}
--
2.21.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] arm: fix page faults in do_alignment
From: Russell King - ARM Linux admin @ 2019-08-31 7:55 UTC (permalink / raw)
To: Jing Xiangfeng
Cc: kstewart, gustavo, gregkh, linux-kernel, linux-mm, ebiederm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <5D69D239.2080908@huawei.com>
On Sat, Aug 31, 2019 at 09:49:45AM +0800, Jing Xiangfeng wrote:
> On 2019/8/30 21:35, Russell King - ARM Linux admin wrote:
> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> >> The function do_alignment can handle misaligned address for user and
> >> kernel space. If it is a userspace access, do_alignment may fail on
> >> a low-memory situation, because page faults are disabled in
> >> probe_kernel_address.
> >>
> >> Fix this by using __copy_from_user stead of probe_kernel_address.
> >>
> >> Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
> >> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
> >
> > NAK.
> >
> > The "scheduling while atomic warning in alignment handling code" is
> > caused by fixing up the page fault while trying to handle the
> > mis-alignment fault generated from an instruction in atomic context.
>
> __might_sleep is called in the function __get_user which lead to that bug.
> And that bug is triggered in a kernel space. Page fault can not be generated.
> Right?
Your email is now fixed?
All of get_user(), __get_user(), copy_from_user() and __copy_from_user()
_can_ cause a page fault, which might need to fetch the page from disk.
All these four functions are equivalent as far as that goes - and indeed
as are their versions that write as well.
If the page needs to come from disk, all of these functions _will_
sleep. If they are called from an atomic context, and the page fault
handler needs to fetch data from disk, they will attempt to sleep,
which will issue a warning.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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] Revert "asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro"
From: Christoph Hellwig @ 2019-08-31 8:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rich Felker, Linux-sh list, Benjamin Herrenschmidt,
Heiko Carstens, Linux Kernel Mailing List, James E.J. Bottomley,
Max Filippov, Guo Ren, H. Peter Anvin, sparclinux,
Vincenzo Frascino, Will Deacon, linux-arch, linux-s390,
Yoshinori Sato, Michael Ellerman, Helge Deller,
the arch/x86 maintainers, Russell King, Christian Borntraeger,
Ingo Molnar, Geert Uytterhoeven, Christian Brauner,
Catalin Marinas, James Hogan, Firoz Khan, Michal Suchanek,
linux-xtensa, Vasily Gorbik, Chris Zankel, linux-m68k,
Borislav Petkov, Alexander Viro, Thomas Gleixner, Linux ARM,
David Howells, Michal Simek, Parisc List, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, Paul Burton,
Linux FS-devel Mailing List, Paul Mackerras, linuxppc-dev,
David S. Miller
In-Reply-To: <CAK8P3a16=ktJm5B3c5-XS7SqVuHBY5+E2FwVUqbdOdWK-AUgSA@mail.gmail.com>
On Fri, Aug 30, 2019 at 09:54:43PM +0200, Arnd Bergmann wrote:
> > -#if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT)
> > +#ifdef __ARCH_WANT_SYS_LLSEEK
> > SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned long, offset_high,
> > unsigned long, offset_low, loff_t __user *, result,
> > unsigned int, whence)
>
> However, only reverting the patch will now break all newly added
> 32-bit architectures that don't define __ARCH_WANT_SYS_LLSEEK:
> at least nds32 and riscv32 come to mind, not sure if there is another.
>
> I think the easiest way however would be to combine the two checks
> above and make it
>
> #if !defined(CONFIG_64BIT) || defined(CONFIG_COMPAT) ||
> defined(__ARCH_WANT_SYS_LLSEEK)
>
> and then only set __ARCH_WANT_SYS_LLSEEK for powerpc.
I'd much rather introduce a CONFIG_SYS_LLSEEK Kconfig symbol, selected
by CONFIG_64BIT and CONFIG_COMPAT by default, plus manually by powerpc.
_______________________________________________
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 2/9] x86: numa: check the node id consistently for x86
From: Peter Zijlstra @ 2019-08-31 8:55 UTC (permalink / raw)
To: Yunsheng Lin
Cc: dalias, linux-sh, catalin.marinas, dave.hansen, heiko.carstens,
linuxarm, jiaxun.yang, linux-mips, mwb, paulus, hpa, sparclinux,
chenhc, will, cai, linux-s390, ysato, mpe, x86, rppt, borntraeger,
dledford, mingo, jeffrey.t.kirsher, benh, jhogan, nfont, mattst88,
len.brown, gor, anshuman.khandual, bp, luto, tglx, naveen.n.rao,
linux-arm-kernel, rth, axboe, linuxppc-dev, linux-kernel, ralf,
tbogendoerfer, paul.burton, linux-alpha, ink, akpm, robin.murphy,
davem
In-Reply-To: <1567231103-13237-3-git-send-email-linyunsheng@huawei.com>
On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> of proximity domain is optional, as below:
>
> This optional object is used to describe proximity domain
> associations within a machine. _PXM evaluates to an integer
> that identifies a device as belonging to a Proximity Domain
> defined in the System Resource Affinity Table (SRAT).
That's just words.. what does it actually mean?
> This patch checks node id with the below case before returning
> node_to_cpumask_map[node]:
> 1. if node_id >= nr_node_ids, return cpu_none_mask
> 2. if node_id < 0, return cpu_online_mask
> 3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
>
> [1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
> arch/x86/include/asm/topology.h | 6 ++++++
> arch/x86/mm/numa.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index 4b14d23..f36e9c8 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -69,6 +69,12 @@ extern const struct cpumask *cpumask_of_node(int node);
> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> static inline const struct cpumask *cpumask_of_node(int node)
> {
> + if (node >= nr_node_ids)
> + return cpu_none_mask;
> +
> + if (node < 0 || !node_to_cpumask_map[node])
> + return cpu_online_mask;
> +
> return node_to_cpumask_map[node];
> }
> #endif
I _reallly_ hate this. Users are expected to use valid numa ids. Now
we're adding all this checking to all users. Why do we want to do that?
Using '(unsigned)node >= nr_nods_ids' is an error.
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index e6dad60..5e393d2 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -868,7 +868,7 @@ const struct cpumask *cpumask_of_node(int node)
> dump_stack();
> return cpu_none_mask;
> }
> - if (node_to_cpumask_map[node] == NULL) {
> + if (node < 0 || !node_to_cpumask_map[node]) {
> printk(KERN_WARNING
> "cpumask_of_node(%d): no node_to_cpumask_map!\n",
> node);
> --
> 2.8.1
>
_______________________________________________
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 7/9] sparc64: numa: check the node id consistently for sparc64
From: Yunsheng Lin @ 2019-08-31 8:57 UTC (permalink / raw)
To: David Miller
Cc: dalias, linux-sh, peterz, catalin.marinas, dave.hansen,
heiko.carstens, linuxarm, jiaxun.yang, linux-mips, mwb, paulus,
hpa, sparclinux, chenhc, will, cai, linux-s390, ysato, mpe, x86,
rppt, borntraeger, dledford, mingo, jeffrey.t.kirsher, benh,
jhogan, nfont, mattst88, len.brown, gor, anshuman.khandual, bp,
luto, tglx, naveen.n.rao, linux-arm-kernel, rth, axboe,
linuxppc-dev, linux-kernel, ralf, tbogendoerfer, paul.burton,
linux-alpha, ink, akpm, robin.murphy
In-Reply-To: <20190830.235337.570776316111294728.davem@davemloft.net>
On 2019/8/31 14:53, David Miller wrote:
> From: Yunsheng Lin <linyunsheng@huawei.com>
> Date: Sat, 31 Aug 2019 13:58:21 +0800
>
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>
> What in the world does the ACPI spec have to do with sparc64 NUMA
> node ID checking?
I am not sure I understand your question fully here.
Here is my issue when the bios does not implement the proximity domain
of a device because the feature is optional according to the ACPI spec,
the dev_to_node(dev) return -1, which causes out of bound access when
using the value to get the device's cpu mask by calling cpumask_of_node.
Did you mean sparc64 system does not has ACPI, the device's node id will
not specified by ACPI, so the ACPI is unrelated here?
Or did you mean the commit log is not clear enough to justify the change?
Or did you mean this problem should be fixed in somewhere else?
Any detail advice and suggestion will be very helpful, thanks.
>
> .
>
_______________________________________________
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: fix page faults in do_alignment
From: Jing Xiangfeng @ 2019-08-31 9:16 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: kstewart, gustavo, gregkh, linux-kernel, linux-mm, ebiederm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <20190831075524.GI13294@shell.armlinux.org.uk>
On 2019/8/31 15:55, Russell King - ARM Linux admin wrote:
> On Sat, Aug 31, 2019 at 09:49:45AM +0800, Jing Xiangfeng wrote:
>> On 2019/8/30 21:35, Russell King - ARM Linux admin wrote:
>>> On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>>>> The function do_alignment can handle misaligned address for user and
>>>> kernel space. If it is a userspace access, do_alignment may fail on
>>>> a low-memory situation, because page faults are disabled in
>>>> probe_kernel_address.
>>>>
>>>> Fix this by using __copy_from_user stead of probe_kernel_address.
>>>>
>>>> Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
>>>> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>>>
>>> NAK.
>>>
>>> The "scheduling while atomic warning in alignment handling code" is
>>> caused by fixing up the page fault while trying to handle the
>>> mis-alignment fault generated from an instruction in atomic context.
>>
>> __might_sleep is called in the function __get_user which lead to that bug.
>> And that bug is triggered in a kernel space. Page fault can not be generated.
>> Right?
>
> Your email is now fixed?
Yeah, I just checked the mailbox, it is normal now.
>
> All of get_user(), __get_user(), copy_from_user() and __copy_from_user()
> _can_ cause a page fault, which might need to fetch the page from disk.
> All these four functions are equivalent as far as that goes - and indeed
> as are their versions that write as well.
>
> If the page needs to come from disk, all of these functions _will_
> sleep. If they are called from an atomic context, and the page fault
> handler needs to fetch data from disk, they will attempt to sleep,
> which will issue a warning.
>
I understand.
Thanks
_______________________________________________
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 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
From: Simon Horman @ 2019-08-31 9:48 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-renesas-soc, Magnus Damm, linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
On Wed, Aug 28, 2019 at 01:36:11PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> Recent R-Car Gen3 SoCs added an External Request Mask Register to the
> System Controller (SYSC). This register allows to mask external power
> requests for CPU or 3DG domains, to prevent conflicts between powering
> off CPU cores or the 3D Graphics Engine, and changing the state of
> another power domain through SYSC, which could lead to CPG state machine
> lock-ups.
>
> This patch series starts making use of this register. Note that the
> register is optional, and that its location and contents are
> SoC-specific.
>
> This was inspired by a patch in the BSP by Dien Pham
> <dien.pham.ry@renesas.com>.
>
> Note that the issue fixed cannot happen in the upstream kernel, as
> upstream has no support for graphics acceleration yet. SoCs lacking the
> External Request Mask Register may need a different mitigation in the
> future.
>
> Changes compared to v1[1]:
> - Improve description of cover letter and first patch.
>
> Changes compared to RFC[2]:
> - Rebased.
>
> This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
> V3M, and E3 (only the last 3 have this register!), and regression-tested
> on R-Car Gen2.
>
> This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
>
> For your convenience, this series is available in the
> topic/rcar3-sysc-extmask-v2 branch of my renesas-drivers git repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> Thanks for your comments!
Looks good to me.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
_______________________________________________
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 1/1] i2c: iproc: Add i2c repeated start capability
From: Wolfram Sang @ 2019-08-31 9:49 UTC (permalink / raw)
To: Ray Jui
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
Shivaraj Shetty, Rayagonda Kokatanur, linux-kernel, Icarus Chau,
Rob Herring, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <3e70fa7e-de13-4edd-2e17-b7c56e91d220@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 781 bytes --]
Hi Ray,
> > With all the limitations in place, I wonder if it might be easier to
> > implement an smbus_xfer callback instead? What is left that makes this
> > controller more than SMBus and real I2C?
> >
>
> Right. But what is the implication of using smbus_xfer instead of
> master_xfer in our driver?
>
> Does it mean it will break existing functions of the i2c app that our
> customers developed based on i2cdev (e.g., I2C_RDWR)?
If the customers uses I2C_RDWR (and it cannot be mapped to i2c_smbus_*
calls) then this is an indication that there is some I2C functionality
left which the HW can provide. I'd be interested which one, though.
>
> 1) Does
Maybe you wanted to describe it here and it got accidently cut off?
Regards,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/9] x86: numa: check the node id consistently for x86
From: Yunsheng Lin @ 2019-08-31 10:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: dalias, linux-sh, catalin.marinas, dave.hansen, heiko.carstens,
linuxarm, jiaxun.yang, linux-mips, mwb, paulus, hpa, sparclinux,
chenhc, will, cai, linux-s390, ysato, mpe, x86, rppt, borntraeger,
dledford, mingo, jeffrey.t.kirsher, benh, jhogan, nfont, mattst88,
len.brown, gor, anshuman.khandual, bp, luto, tglx, naveen.n.rao,
linux-arm-kernel, rth, axboe, linuxppc-dev, linux-kernel, ralf,
tbogendoerfer, paul.burton, linux-alpha, ink, akpm, robin.murphy,
davem
In-Reply-To: <20190831085539.GG2369@hirez.programming.kicks-ass.net>
On 2019/8/31 16:55, Peter Zijlstra wrote:
> On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
>> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
>> of proximity domain is optional, as below:
>>
>> This optional object is used to describe proximity domain
>> associations within a machine. _PXM evaluates to an integer
>> that identifies a device as belonging to a Proximity Domain
>> defined in the System Resource Affinity Table (SRAT).
>
> That's just words.. what does it actually mean?
It means the dev_to_node(dev) may return -1 if the bios does not
implement the proximity domain feature, user may use that value
to call cpumask_of_node and cpumask_of_node does not protect itself
from node id being -1, which causes out of bound access.
>
>> This patch checks node id with the below case before returning
>> node_to_cpumask_map[node]:
>> 1. if node_id >= nr_node_ids, return cpu_none_mask
>> 2. if node_id < 0, return cpu_online_mask
>> 3. if node_to_cpumask_map[node_id] is NULL, return cpu_online_mask
>>
>> [1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
>>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>> arch/x86/include/asm/topology.h | 6 ++++++
>> arch/x86/mm/numa.c | 2 +-
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
>> index 4b14d23..f36e9c8 100644
>> --- a/arch/x86/include/asm/topology.h
>> +++ b/arch/x86/include/asm/topology.h
>> @@ -69,6 +69,12 @@ extern const struct cpumask *cpumask_of_node(int node);
>> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
>> static inline const struct cpumask *cpumask_of_node(int node)
>> {
>> + if (node >= nr_node_ids)
>> + return cpu_none_mask;
>> +
>> + if (node < 0 || !node_to_cpumask_map[node])
>> + return cpu_online_mask;
>> +
>> return node_to_cpumask_map[node];
>> }
>> #endif
>
> I _reallly_ hate this. Users are expected to use valid numa ids. Now
> we're adding all this checking to all users. Why do we want to do that?
As above, the dev_to_node(dev) may return -1.
>
> Using '(unsigned)node >= nr_nods_ids' is an error.
'node >= nr_node_ids' can be dropped if all user is expected to not call
cpumask_of_node with node id greater or equal to nr_nods_ids.
From what I can see, the problem can be fixed in three place:
1. Make user dev_to_node return a valid node id even when proximity
domain is not set by bios(or node id set by buggy bios is not valid),
which may need info from the numa system to make sure it will return
a valid node.
2. User that call cpumask_of_node should ensure the node id is valid
before calling cpumask_of_node, and user also need some info to
make ensure node id is valid.
3. Make sure cpumask_of_node deal with invalid node id as this patchset.
Which one do you prefer to make sure node id is valid, or do you
have any better idea?
Any detail advice and suggestion will be very helpful, thanks.
>
>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
>> index e6dad60..5e393d2 100644
>> --- a/arch/x86/mm/numa.c
>> +++ b/arch/x86/mm/numa.c
>> @@ -868,7 +868,7 @@ const struct cpumask *cpumask_of_node(int node)
>> dump_stack();
>> return cpu_none_mask;
>> }
>> - if (node_to_cpumask_map[node] == NULL) {
>> + if (node < 0 || !node_to_cpumask_map[node]) {
>> printk(KERN_WARNING
>> "cpumask_of_node(%d): no node_to_cpumask_map!\n",
>> node);
>> --
>> 2.8.1
>>
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Wolfram Sang @ 2019-08-31 11:39 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, alexandre.belloni, linux-kernel,
pierre-yves.mordret, Ludovic.Desroches, robh+dt, linux-i2c, peda,
linux-arm-kernel
In-Reply-To: <1562678049-17581-3-git-send-email-eugen.hristev@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 1644 bytes --]
On Tue, Jul 09, 2019 at 01:19:33PM +0000, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> Some i2c controllers have a built-in digital or analog filter.
> This is specifically required depending on the hardware PCB/board.
> Some controllers also allow specifying the maximum width of the
> spikes that can be filtered. The width length can be specified in nanoseconds.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index 44efafd..a2d31aa 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
> specification.
>
> +- i2c-ana-filter
> + Enable analog filter for i2c lines.
> +
> +- i2c-dig-filter
> + Enable digital filter for i2c lines.
Would you be OK with writing out 'analog' and 'digital' in full form?
The abrreviation doesn't save us much, I'd think, and I didn't find
similar wording in existing bindings.
> +
> +- i2c-filter-width-ns
> + Width of spikes which can be filtered by either digital or analog
> + filters (i2c-ana-filtr or i2c-dig-filtr). This width is specified
> + in nanoseconds.
> +
> - interrupts
> interrupts used by the device.
>
> --
> 2.7.4
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/9] i2c: at91: add support for digital filtering
From: Wolfram Sang @ 2019-08-31 12:13 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, alexandre.belloni, linux-kernel,
pierre-yves.mordret, Ludovic.Desroches, robh+dt, linux-i2c, peda,
linux-arm-kernel
In-Reply-To: <1562678049-17581-6-git-send-email-eugen.hristev@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]
> diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
> index a663a7a..62610af 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
> .has_unre_flag = true,
> .has_alt_cmd = false,
> .has_hold_field = false,
> + .has_dig_filtr = false,
Hmm, 'false' is the default. Maybe not for this series, but it might
make sense to clean up the driver afterwards removing the superfluous
'false'. The precedence will make adding new properties much simpler.
> + dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
> + "i2c-dig-filter");
> +
What do you think of the idea to introduce 'flags' to struct i2c_timings
and parse the bindings in the core, too? Then you'd have sth like:
if (t->flags & I2C_TIMINGS_ANALOG_FILTER)
Would that be useful for you?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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