* [PATCH v2 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: Gautham R. Shenoy @ 2020-12-09 17:08 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On POWER platforms where only some groups of threads within a core
share the L2-cache (indicated by the ibm,thread-groups device-tree
property), we currently print the incorrect shared_cpu_map/list for
L2-cache in the sysfs.
This patch reports the correct shared_cpu_map/list on such platforms.
Example:
On a platform with "ibm,thread-groups" set to
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
This indicates that threads {0,2,4,6} in the core share the L2-cache
and threads {1,3,5,7} in the core share the L2 cache.
However, without the patch, the shared_cpu_map/list for L2 for CPUs 0,
1 is reported in the sysfs as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,000000ff
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:0-7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000ff
With the patch, the shared_cpu_map/list for L2 cache for CPUs 0, 1 is
correctly reported as follows:
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,00000055
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:1,3,5,7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000aa
This patch adds #CONFIG_PPC64 checks for these cases to ensure that
32-bit configs build correctly.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 34 ++++++++++++++++++++++++----------
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 65ab9fc..cb87b68 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -641,6 +641,7 @@ static ssize_t level_show(struct kobject *k, struct kobj_attribute *attr, char *
static struct kobj_attribute cache_level_attr =
__ATTR(level, 0444, level_show, NULL);
+#ifdef CONFIG_PPC64
static unsigned int index_dir_to_cpu(struct cache_index_dir *index)
{
struct kobject *index_dir_kobj = &index->kobj;
@@ -650,16 +651,35 @@ static unsigned int index_dir_to_cpu(struct cache_index_dir *index)
return dev->id;
}
+#endif
/*
* On big-core systems, each core has two groups of CPUs each of which
* has its own L1-cache. The thread-siblings which share l1-cache with
* @cpu can be obtained via cpu_smallcore_mask().
+ *
+ * On some big-core systems, the L2 cache is shared only between some
+ * groups of siblings. This is already parsed and encoded in
+ * cpu_l2_cache_mask().
+ *
+ * TODO: cache_lookup_or_instantiate() needs to be made aware of the
+ * "ibm,thread-groups" property so that cache->shared_cpu_map
+ * reflects the correct siblings on platforms that have this
+ * device-tree property. This helper function is only a stop-gap
+ * solution so that we report the correct siblings to the
+ * userspace via sysfs.
*/
-static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
+static const struct cpumask *get_shared_cpu_map(struct cache_index_dir *index, struct cache *cache)
{
- if (cache->level == 1)
- return cpu_smallcore_mask(cpu);
+#ifdef CONFIG_PPC64
+ if (has_big_cores) {
+ int cpu = index_dir_to_cpu(index);
+ if (cache->level == 1)
+ return cpu_smallcore_mask(cpu);
+ if (cache->level == 2 && thread_group_shares_l2)
+ return cpu_l2_cache_mask(cpu);
+ }
+#endif
return &cache->shared_cpu_map;
}
@@ -670,17 +690,11 @@ static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *
struct cache_index_dir *index;
struct cache *cache;
const struct cpumask *mask;
- int cpu;
index = kobj_to_cache_index_dir(k);
cache = index->cache;
- if (has_big_cores) {
- cpu = index_dir_to_cpu(index);
- mask = get_big_core_shared_cpu_map(cpu, cache);
- } else {
- mask = &cache->shared_cpu_map;
- }
+ mask = get_shared_cpu_map(index, cache);
return cpumap_print_to_pagebuf(list, buf, mask);
}
--
1.9.4
^ permalink raw reply related
* [PATCH v2 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: Gautham R. Shenoy @ 2020-12-09 17:08 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On POWER systems, groups of threads within a core sharing the L2-cache
can be indicated by the "ibm,thread-groups" property array with the
identifier "2".
This patch adds support for detecting this, and when present, populate
the populating the cpu_l2_cache_mask of every CPU to the core-siblings
which share L2 with the CPU as specified in the by the
"ibm,thread-groups" property array.
On a platform with the following "ibm,thread-group" configuration
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
With this patch, the sched-domain hierarchy for CPUs 0,1 would be
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 1 +
arch/powerpc/kernel/smp.c | 56 +++++++++++++++++++++++++++++++++++++++---
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index b2035b2..8d3d081 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -134,6 +134,7 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
extern bool has_big_cores;
+extern bool thread_group_shares_l2;
#define cpu_smt_mask cpu_smt_mask
#ifdef CONFIG_SCHED_SMT
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 9078b5b5..a46cf3f 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,7 @@
struct task_struct *secondary_current;
bool has_big_cores;
bool coregroup_enabled;
+bool thread_group_shares_l2;
DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
DEFINE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
@@ -99,6 +100,7 @@ enum {
#define MAX_THREAD_LIST_SIZE 8
#define THREAD_GROUP_SHARE_L1 1
+#define THREAD_GROUP_SHARE_L2 2
struct thread_groups {
unsigned int property;
unsigned int nr_groups;
@@ -107,7 +109,7 @@ struct thread_groups {
};
/* Maximum number of properties that groups of threads within a core can share */
-#define MAX_THREAD_GROUP_PROPERTIES 1
+#define MAX_THREAD_GROUP_PROPERTIES 2
struct thread_groups_list {
unsigned int nr_properties;
@@ -121,6 +123,13 @@ struct thread_groups_list {
*/
DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+/*
+ * On some big-cores system, thread_group_l2_cache_map for each CPU
+ * corresponds to the set its siblings within the core that share the
+ * L2-cache.
+ */
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -718,7 +727,9 @@ static void or_cpumasks_related(int i, int j, struct cpumask *(*srcmask)(int),
*
* ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
- * that the threads in the same group share L1, translation cache.
+ * that the threads in the same group share L1, translation cache. If
+ * the value is 2, it implies that the threads in the same group share
+ * the same L2 cache.
*
* ibm,thread-groups[i+1] tells us how many such thread groups exist for the
* property ibm,thread-groups[i]
@@ -874,7 +885,8 @@ static int __init init_thread_group_cache_map(int cpu, int cache_property)
struct thread_groups *tg = NULL;
cpumask_var_t *mask;
- if (cache_property != THREAD_GROUP_SHARE_L1)
+ if (cache_property != THREAD_GROUP_SHARE_L1 &&
+ cache_property != THREAD_GROUP_SHARE_L2)
return -EINVAL;
tg = get_thread_groups(cpu, cache_property, &err);
@@ -888,7 +900,11 @@ static int __init init_thread_group_cache_map(int cpu, int cache_property)
return -ENODATA;
}
- mask = &per_cpu(thread_group_l1_cache_map, cpu);
+ if (cache_property == THREAD_GROUP_SHARE_L1)
+ mask = &per_cpu(thread_group_l1_cache_map, cpu);
+ else if (cache_property == THREAD_GROUP_SHARE_L2)
+ mask = &per_cpu(thread_group_l2_cache_map, cpu);
+
zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -990,6 +1006,16 @@ static int init_big_cores(void)
}
has_big_cores = true;
+
+ for_each_possible_cpu(cpu) {
+ int err = init_thread_group_cache_map(cpu, THREAD_GROUP_SHARE_L2);
+
+ if (err)
+ return err;
+ }
+
+ thread_group_shares_l2 = true;
+ pr_debug("L2 cache only shared by the threads in the small core\n");
return 0;
}
@@ -1304,6 +1330,28 @@ static bool update_mask_by_l2(int cpu, cpumask_var_t *mask)
if (has_big_cores)
submask_fn = cpu_smallcore_mask;
+ /*
+ * If the threads in a thread-group share L2 cache, then then
+ * the L2-mask can be obtained from thread_group_l2_cache_map.
+ */
+ if (thread_group_shares_l2) {
+ cpumask_set_cpu(cpu, cpu_l2_cache_mask(cpu));
+
+ for_each_cpu(i, per_cpu(thread_group_l2_cache_map, cpu)) {
+ if (cpu_online(i))
+ set_cpus_related(i, cpu, cpu_l2_cache_mask);
+ }
+
+ /* Verify that L1-cache siblings are a subset of L2 cache-siblings */
+ if (!cpumask_equal(submask_fn(cpu), cpu_l2_cache_mask(cpu)) &&
+ !cpumask_subset(submask_fn(cpu), cpu_l2_cache_mask(cpu))) {
+ pr_warn_once("CPU %d : Inconsistent L1 and L2 cache siblings\n",
+ cpu);
+ }
+
+ return true;
+ }
+
l2_cache = cpu_to_l2cache(cpu);
if (!l2_cache || !*mask) {
/* Assume only core siblings share cache with this CPU */
--
1.9.4
^ permalink raw reply related
* [PATCH v2 1/5] powerpc/smp: Parse ibm, thread-groups with multiple properties
From: Gautham R. Shenoy @ 2020-12-09 17:08 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
This patch extends the parsing support on platforms which encode
information about multiple properties being shared by the
corresponding groups of threads.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 174 ++++++++++++++++++++++++++++++----------------
1 file changed, 113 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8c2857c..88d88ad 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -106,6 +106,15 @@ struct thread_groups {
unsigned int thread_list[MAX_THREAD_LIST_SIZE];
};
+/* Maximum number of properties that groups of threads within a core can share */
+#define MAX_THREAD_GROUP_PROPERTIES 1
+
+struct thread_groups_list {
+ unsigned int nr_properties;
+ struct thread_groups property_tgs[MAX_THREAD_GROUP_PROPERTIES];
+};
+
+static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
* On big-cores system, cpu_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
@@ -695,81 +704,98 @@ static void or_cpumasks_related(int i, int j, struct cpumask *(*srcmask)(int),
/*
* parse_thread_groups: Parses the "ibm,thread-groups" device tree
* property for the CPU device node @dn and stores
- * the parsed output in the thread_groups
- * structure @tg if the ibm,thread-groups[0]
- * matches @property.
+ * the parsed output in the thread_groups_list
+ * structure @tglp.
*
* @dn: The device node of the CPU device.
- * @tg: Pointer to a thread group structure into which the parsed
+ * @tglp: Pointer to a thread group list structure into which the parsed
* output of "ibm,thread-groups" is stored.
- * @property: The property of the thread-group that the caller is
- * interested in.
*
* ibm,thread-groups[0..N-1] array defines which group of threads in
* the CPU-device node can be grouped together based on the property.
*
- * ibm,thread-groups[0] tells us the property based on which the
+ * This array can represent thread groupings for multiple properties.
+ *
+ * ibm,thread-groups[i + 0] tells us the property based on which the
* threads are being grouped together. If this value is 1, it implies
* that the threads in the same group share L1, translation cache.
*
- * ibm,thread-groups[1] tells us how many such thread groups exist.
+ * ibm,thread-groups[i+1] tells us how many such thread groups exist for the
+ * property ibm,thread-groups[i]
*
- * ibm,thread-groups[2] tells us the number of threads in each such
+ * ibm,thread-groups[i+2] tells us the number of threads in each such
* group.
+ * Suppose k = (ibm,thread-groups[i+1] * ibm,thread-groups[i+2]), then,
*
- * ibm,thread-groups[3..N-1] is the list of threads identified by
+ * ibm,thread-groups[i+3..i+k+2] (is the list of threads identified by
* "ibm,ppc-interrupt-server#s" arranged as per their membership in
* the grouping.
*
- * Example: If ibm,thread-groups = [1,2,4,5,6,7,8,9,10,11,12] it
- * implies that there are 2 groups of 4 threads each, where each group
- * of threads share L1, translation cache.
+ * Example:
+ * If "ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
+ * This can be decomposed up into two consecutive arrays:
+ * a) [1,2,4,8,10,12,14,9,11,13,15]
+ * b) [2,2,4,8,10,12,14,9,11,13,15]
+ *
+ * where in,
+ *
+ * a) provides information of Property "1" being shared by "2" groups,
+ * each with "4" threads each. The "ibm,ppc-interrupt-server#s" of
+ * the first group is {8,10,12,14} and the
+ * "ibm,ppc-interrupt-server#s" of the second group is
+ * {9,11,13,15}. Property "1" is indicative of the thread in the
+ * group sharing L1 cache, translation cache and Instruction Data
+ * flow.
*
- * The "ibm,ppc-interrupt-server#s" of the first group is {5,6,7,8}
- * and the "ibm,ppc-interrupt-server#s" of the second group is {9, 10,
- * 11, 12} structure
+ * b) provides information of Property "2" being shared by "2" groups,
+ * each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
+ * the first group is {8,10,12,14} and the
+ * "ibm,ppc-interrupt-server#s" of the second group is
+ * {9,11,13,15}. Property "2" indicates that the threads in each
+ * group share the L2-cache.
*
* Returns 0 on success, -EINVAL if the property does not exist,
* -ENODATA if property does not have a value, and -EOVERFLOW if the
* property data isn't large enough.
*/
static int parse_thread_groups(struct device_node *dn,
- struct thread_groups *tg,
- unsigned int property)
+ struct thread_groups_list *tglp)
{
- int i;
- u32 thread_group_array[3 + MAX_THREAD_LIST_SIZE];
- u32 *thread_list;
+ unsigned int property_idx = 0;
+ u32 *thread_group_array;
size_t total_threads;
- int ret;
+ int ret = 0, count;
+ u32 *thread_list;
+ int i = 0;
+ count = of_property_count_u32_elems(dn, "ibm,thread-groups");
+ thread_group_array = kcalloc(count, sizeof(u32), GFP_KERNEL);
ret = of_property_read_u32_array(dn, "ibm,thread-groups",
- thread_group_array, 3);
+ thread_group_array, count);
if (ret)
- return ret;
-
- tg->property = thread_group_array[0];
- tg->nr_groups = thread_group_array[1];
- tg->threads_per_group = thread_group_array[2];
- if (tg->property != property ||
- tg->nr_groups < 1 ||
- tg->threads_per_group < 1)
- return -ENODATA;
+ goto out_free;
- total_threads = tg->nr_groups * tg->threads_per_group;
+ while (i < count && property_idx < MAX_THREAD_GROUP_PROPERTIES) {
+ int j;
+ struct thread_groups *tg = &tglp->property_tgs[property_idx++];
- ret = of_property_read_u32_array(dn, "ibm,thread-groups",
- thread_group_array,
- 3 + total_threads);
- if (ret)
- return ret;
+ tg->property = thread_group_array[i];
+ tg->nr_groups = thread_group_array[i + 1];
+ tg->threads_per_group = thread_group_array[i + 2];
+ total_threads = tg->nr_groups * tg->threads_per_group;
- thread_list = &thread_group_array[3];
+ thread_list = &thread_group_array[i + 3];
- for (i = 0 ; i < total_threads; i++)
- tg->thread_list[i] = thread_list[i];
+ for (j = 0; j < total_threads; j++)
+ tg->thread_list[j] = thread_list[j];
+ i = i + 3 + total_threads;
+ }
- return 0;
+ tglp->nr_properties = property_idx;
+
+out_free:
+ kfree(thread_group_array);
+ return ret;
}
/*
@@ -805,50 +831,76 @@ static int get_cpu_thread_group_start(int cpu, struct thread_groups *tg)
return -1;
}
+static struct thread_groups *__init get_thread_groups(int cpu,
+ int group_property,
+ int *err)
+{
+ struct device_node *dn = of_get_cpu_node(cpu, NULL);
+ struct thread_groups_list *cpu_tgl = &tgl[cpu];
+ struct thread_groups *tg = NULL;
+ int i;
+ *err = 0;
+
+ if (!dn) {
+ *err = -ENODATA;
+ return NULL;
+ }
+
+ if (!cpu_tgl->nr_properties) {
+ *err = parse_thread_groups(dn, cpu_tgl);
+ if (*err)
+ goto out;
+ }
+
+ for (i = 0; i < cpu_tgl->nr_properties; i++) {
+ if (cpu_tgl->property_tgs[i].property == group_property) {
+ tg = &cpu_tgl->property_tgs[i];
+ break;
+ }
+ }
+
+ if (!tg)
+ *err = -EINVAL;
+out:
+ of_node_put(dn);
+ return tg;
+}
+
static int init_cpu_l1_cache_map(int cpu)
{
- struct device_node *dn = of_get_cpu_node(cpu, NULL);
- struct thread_groups tg = {.property = 0,
- .nr_groups = 0,
- .threads_per_group = 0};
int first_thread = cpu_first_thread_sibling(cpu);
int i, cpu_group_start = -1, err = 0;
+ struct thread_groups *tg = NULL;
- if (!dn)
- return -ENODATA;
-
- err = parse_thread_groups(dn, &tg, THREAD_GROUP_SHARE_L1);
- if (err)
- goto out;
+ tg = get_thread_groups(cpu, THREAD_GROUP_SHARE_L1,
+ &err);
+ if (!tg)
+ return err;
- cpu_group_start = get_cpu_thread_group_start(cpu, &tg);
+ cpu_group_start = get_cpu_thread_group_start(cpu, tg);
if (unlikely(cpu_group_start == -1)) {
WARN_ON_ONCE(1);
- err = -ENODATA;
- goto out;
+ return -ENODATA;
}
zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
- int i_group_start = get_cpu_thread_group_start(i, &tg);
+ int i_group_start = get_cpu_thread_group_start(i, tg);
if (unlikely(i_group_start == -1)) {
WARN_ON_ONCE(1);
- err = -ENODATA;
- goto out;
+ return -ENODATA;
}
if (i_group_start == cpu_group_start)
cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
}
-out:
- of_node_put(dn);
- return err;
+ return 0;
}
static bool shared_caches;
--
1.9.4
^ permalink raw reply related
* [PATCH v2 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
From: Gautham R. Shenoy @ 2020-12-09 17:08 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thread_group_l1_cache_map" to make
it consistent with a subsequent patch which will introduce
thread_group_l2_cache_map.
This patch introduces no functional change.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 88d88ad..f3290d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -116,10 +116,10 @@ struct thread_groups_list {
static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
- * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
+ * On big-cores system, thread_group_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
*/
-DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -866,7 +866,7 @@ static struct thread_groups *__init get_thread_groups(int cpu,
return tg;
}
-static int init_cpu_l1_cache_map(int cpu)
+static int init_thread_group_l1_cache_map(int cpu)
{
int first_thread = cpu_first_thread_sibling(cpu);
@@ -885,7 +885,7 @@ static int init_cpu_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
+ zalloc_cpumask_var_node(&per_cpu(thread_group_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -897,7 +897,7 @@ static int init_cpu_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
+ cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map, cpu));
}
return 0;
@@ -976,7 +976,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_cpu_l1_cache_map(cpu);
+ int err = init_thread_group_l1_cache_map(cpu);
if (err)
return err;
@@ -1372,7 +1372,7 @@ static inline void add_cpu_to_smallcore_masks(int cpu)
cpumask_set_cpu(cpu, cpu_smallcore_mask(cpu));
- for_each_cpu(i, per_cpu(cpu_l1_cache_map, cpu)) {
+ for_each_cpu(i, per_cpu(thread_group_l1_cache_map, cpu)) {
if (cpu_online(i))
set_cpus_related(i, cpu, cpu_smallcore_mask);
}
--
1.9.4
^ permalink raw reply related
* Re: linux-next: build warning after merge of the akpm tree
From: Kees Cook @ 2020-12-09 18:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mathieu Malaterre, Linux Kernel Mailing List, Nicholas Piggin,
Linux Next Mailing List, Andrew Morton, PowerPC
In-Reply-To: <20201208230157.42c42789@canb.auug.org.au>
On Tue, Dec 08, 2020 at 11:01:57PM +1100, Stephen Rothwell wrote:
> Hi Stephen,
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the akpm tree, today's linux-next build (powerpc
> > allyesconfig) produced warnings like this:
> >
> > ld: warning: orphan section `.data..Lubsan_data177' from `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section `.data..Lubsan_data177'
> >
> > (lots of these latter ones)
>
> 781584 of them today!
>
> > I don't know what produced these, but it is in the akpm-current or
> > akpm trees.
>
> Presumably the result of commit
>
> 186c3e18dba3 ("ubsan: enable for all*config builds")
>
> from the akpm-current tree.
>
> arch/powerpc/kernel/vmlinux.lds.S has:
>
> #ifdef CONFIG_PPC32
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> #ifdef CONFIG_UBSAN
> *(.data..Lubsan_data*)
> *(.data..Lubsan_type*)
> #endif
> *(.data.rel*)
> *(SDATA_MAIN)
>
> added by commit
>
> beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")
>
> in 2018, but no equivalent for 64 bit.
>
> I will try the following patch tomorrow:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Dec 2020 22:58:24 +1100
> Subject: [PATCH] powerpc: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly
>
> Similarly to commit
>
> beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly")
>
> since CONFIG_UBSAN bits can now be enabled for all*config.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index 3b4c26e94328..0318ba436f34 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -296,6 +296,10 @@ SECTIONS
> #else
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> +#ifdef CONFIG_UBSAN
> + *(.data..Lubsan_data*)
> + *(.data..Lubsan_type*)
> +#endif
> *(.data.rel*)
> *(.toc1)
> *(.branch_lt)
> --
> 2.29.2
>
> --
> Cheers,
> Stephen Rothwell
Reviewed-by: Kees Cook <keescook@chromium.org>
Thanks for figuring this one out. :) Andrew, can you add this to your
ubsan patch stack, or do you want me to resend it to you directly?
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Vladimir Oltean @ 2020-12-09 20:29 UTC (permalink / raw)
To: Michael Walle
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, Bjorn Helgaas, rjui, f.fainelli,
linux-rpi-kernel, Jonathan.Cameron, bhelgaas, jonathan.derrick,
sbranden, wangzhou1, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <c6d067abcdd5278f259bd7300730dc76@walle.cc>
On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote:
> Hopefully my mail client won't mess up the output that much.
I can reproduce on my LS1028A as well. The following fixes the bug for
me. I did not follow the discussion and see if it is helpful for others.
I don't understand how the bug came to be. There might be more to it
than what I'm seeing. If it's just what I'm seeing, then the patch was
pretty broken to begin with.
-----------------------------[cut here]-----------------------------
From b184da4088c9d39d25fee2486941cdf77688a409 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Wed, 9 Dec 2020 22:17:32 +0200
Subject: [PATCH] PCI: fix invalid window size for the ECAM config space
The blamed commit forgot that pci_ecam_create() calculates the size of
the window for the ECAM's config space based on the spacing between two
buses. The drivers whose .bus_shift from struct pci_ecam_ops was changed
to zero in this commit are now using this invalid value for bus_shift
in calculating the window size.
Before (broken):
pci_ecam_create: remapping config space from addr 0x1f0000000, bus_range 0x1, bsz 0x1
After (fixed/restored):
pci_ecam_create: remapping config space from addr 0x1f0000000, bus_range 0x1, bsz 0x100000
Fixes: f3c07cf6924e ("PCI: Unify ECAM constants in native PCI Express drivers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/pci/ecam.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index 59f91d434859..9fda0d49bc93 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -28,11 +28,19 @@ struct pci_config_window *pci_ecam_create(struct device *dev,
struct resource *cfgres, struct resource *busr,
const struct pci_ecam_ops *ops)
{
+ unsigned int bus_shift = ops->bus_shift;
struct pci_config_window *cfg;
unsigned int bus_range, bus_range_max, bsz;
struct resource *conflict;
int i, err;
+ /*
+ * struct pci_ecam_ops may omit specifying bus_shift
+ * if it is as per spec
+ */
+ if (!bus_shift)
+ bus_shift = PCIE_ECAM_BUS_SHIFT;
+
if (busr->start > busr->end)
return ERR_PTR(-EINVAL);
@@ -46,14 +54,14 @@ struct pci_config_window *pci_ecam_create(struct device *dev,
cfg->busr.end = busr->end;
cfg->busr.flags = IORESOURCE_BUS;
bus_range = resource_size(&cfg->busr);
- bus_range_max = resource_size(cfgres) >> ops->bus_shift;
+ bus_range_max = resource_size(cfgres) >> bus_shift;
if (bus_range > bus_range_max) {
bus_range = bus_range_max;
cfg->busr.end = busr->start + bus_range - 1;
dev_warn(dev, "ECAM area %pR can only accommodate %pR (reduced from %pR desired)\n",
cfgres, &cfg->busr, busr);
}
- bsz = 1 << ops->bus_shift;
+ bsz = 1 << bus_shift;
cfg->res.start = cfgres->start;
cfg->res.end = cfgres->end;
-----------------------------[cut here]-----------------------------
^ permalink raw reply related
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Bjorn Helgaas @ 2020-12-09 20:59 UTC (permalink / raw)
To: Vladimir Oltean
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, rjui, f.fainelli, linux-rpi-kernel,
Jonathan.Cameron, bhelgaas, jonathan.derrick, sbranden, wangzhou1,
Michael Walle, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <20201209202904.2juzokqhleusgsts@skbuf>
On Wed, Dec 09, 2020 at 10:29:04PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 04:40:52PM +0100, Michael Walle wrote:
> > Hopefully my mail client won't mess up the output that much.
>
> I can reproduce on my LS1028A as well. The following fixes the bug for
> me. I did not follow the discussion and see if it is helpful for others.
> I don't understand how the bug came to be. There might be more to it
> than what I'm seeing. If it's just what I'm seeing, then the patch was
> pretty broken to begin with.
>
> -----------------------------[cut here]-----------------------------
> From b184da4088c9d39d25fee2486941cdf77688a409 Mon Sep 17 00:00:00 2001
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Date: Wed, 9 Dec 2020 22:17:32 +0200
> Subject: [PATCH] PCI: fix invalid window size for the ECAM config space
>
> The blamed commit forgot that pci_ecam_create() calculates the size of
> the window for the ECAM's config space based on the spacing between two
> buses. The drivers whose .bus_shift from struct pci_ecam_ops was changed
> to zero in this commit are now using this invalid value for bus_shift
> in calculating the window size.
>
> Before (broken):
> pci_ecam_create: remapping config space from addr 0x1f0000000, bus_range 0x1, bsz 0x1
> After (fixed/restored):
> pci_ecam_create: remapping config space from addr 0x1f0000000, bus_range 0x1, bsz 0x100000
>
> Fixes: f3c07cf6924e ("PCI: Unify ECAM constants in native PCI Express drivers")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> drivers/pci/ecam.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
> index 59f91d434859..9fda0d49bc93 100644
> --- a/drivers/pci/ecam.c
> +++ b/drivers/pci/ecam.c
> @@ -28,11 +28,19 @@ struct pci_config_window *pci_ecam_create(struct device *dev,
> struct resource *cfgres, struct resource *busr,
> const struct pci_ecam_ops *ops)
> {
> + unsigned int bus_shift = ops->bus_shift;
> struct pci_config_window *cfg;
> unsigned int bus_range, bus_range_max, bsz;
> struct resource *conflict;
> int i, err;
>
> + /*
> + * struct pci_ecam_ops may omit specifying bus_shift
> + * if it is as per spec
> + */
> + if (!bus_shift)
> + bus_shift = PCIE_ECAM_BUS_SHIFT;
Yep, that's the theory. Thanks for testing it!
> if (busr->start > busr->end)
> return ERR_PTR(-EINVAL);
>
> @@ -46,14 +54,14 @@ struct pci_config_window *pci_ecam_create(struct device *dev,
> cfg->busr.end = busr->end;
> cfg->busr.flags = IORESOURCE_BUS;
> bus_range = resource_size(&cfg->busr);
> - bus_range_max = resource_size(cfgres) >> ops->bus_shift;
> + bus_range_max = resource_size(cfgres) >> bus_shift;
> if (bus_range > bus_range_max) {
> bus_range = bus_range_max;
> cfg->busr.end = busr->start + bus_range - 1;
> dev_warn(dev, "ECAM area %pR can only accommodate %pR (reduced from %pR desired)\n",
> cfgres, &cfg->busr, busr);
> }
> - bsz = 1 << ops->bus_shift;
> + bsz = 1 << bus_shift;
>
> cfg->res.start = cfgres->start;
> cfg->res.end = cfgres->end;
> -----------------------------[cut here]-----------------------------
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Vladimir Oltean @ 2020-12-09 21:20 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, rjui, f.fainelli, linux-rpi-kernel,
Jonathan.Cameron, bhelgaas, jonathan.derrick, sbranden, wangzhou1,
Michael Walle, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <20201209205913.GA2543692@bjorn-Precision-5520>
On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> Yep, that's the theory. Thanks for testing it!
Testing what? I'm not following.
^ permalink raw reply
* Re: [RESEND v1 5/5] powerpc/platforms: Move files from 4xx to 44x
From: kernel test robot @ 2020-12-09 21:22 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, kbuild-all, linux-kernel
In-Reply-To: <5e968da2216f4d2d8da521498dad6870fcaa4e11.1607519517.git.christophe.leroy@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 7699 bytes --]
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20201209]
[cannot apply to robh/for-next linus/master mpe/next v5.10-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-40x-Remove-40x-platforms/20201209-211628
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-m031-20201210 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/27cc6cb808696f690aaad90722175809739de5bc
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Christophe-Leroy/powerpc-40x-Remove-40x-platforms/20201209-211628
git checkout 27cc6cb808696f690aaad90722175809739de5bc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> arch/powerpc/platforms/44x/uic.c:275:13: error: no previous prototype for 'uic_init_tree' [-Werror=missing-prototypes]
275 | void __init uic_init_tree(void)
| ^~~~~~~~~~~~~
>> arch/powerpc/platforms/44x/uic.c:320:14: error: no previous prototype for 'uic_get_irq' [-Werror=missing-prototypes]
320 | unsigned int uic_get_irq(void)
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
--
>> arch/powerpc/platforms/44x/soc.c:193:6: error: no previous prototype for 'ppc4xx_reset_system' [-Werror=missing-prototypes]
193 | void ppc4xx_reset_system(char *cmd)
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
--
>> arch/powerpc/platforms/44x/msi.c:109:6: error: no previous prototype for 'ppc4xx_teardown_msi_irqs' [-Werror=missing-prototypes]
109 | void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
vim +/uic_init_tree +275 arch/powerpc/platforms/44x/uic.c
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 274
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 @275 void __init uic_init_tree(void)
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 276 {
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 277 struct device_node *np;
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 278 struct uic *uic;
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 279 const u32 *interrupts;
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 280
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 281 /* First locate and initialize the top-level UIC */
26cb7d8bbddc83 arch/powerpc/sysdev/uic.c Cyrill Gorcunov 2007-11-30 282 for_each_compatible_node(np, NULL, "ibm,uic") {
12d371a69e6df9 arch/powerpc/sysdev/uic.c Stephen Rothwell 2007-04-29 283 interrupts = of_get_property(np, "interrupts", NULL);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 284 if (!interrupts)
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 285 break;
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 286 }
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 287
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 288 BUG_ON(!np); /* uic_init_tree() assumes there's a UIC as the
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 289 * top-level interrupt controller */
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 290 primary_uic = uic_init_one(np);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 291 if (!primary_uic)
b7c670d673d118 arch/powerpc/platforms/4xx/uic.c Rob Herring 2017-08-21 292 panic("Unable to initialize primary UIC %pOF\n", np);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 293
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 294 irq_set_default_host(primary_uic->irqhost);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 295 of_node_put(np);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 296
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 297 /* The scan again for cascaded UICs */
26cb7d8bbddc83 arch/powerpc/sysdev/uic.c Cyrill Gorcunov 2007-11-30 298 for_each_compatible_node(np, NULL, "ibm,uic") {
12d371a69e6df9 arch/powerpc/sysdev/uic.c Stephen Rothwell 2007-04-29 299 interrupts = of_get_property(np, "interrupts", NULL);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 300 if (interrupts) {
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 301 /* Secondary UIC */
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 302 int cascade_virq;
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 303
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 304 uic = uic_init_one(np);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 305 if (! uic)
b7c670d673d118 arch/powerpc/platforms/4xx/uic.c Rob Herring 2017-08-21 306 panic("Unable to initialize a secondary UIC %pOF\n",
b7c670d673d118 arch/powerpc/platforms/4xx/uic.c Rob Herring 2017-08-21 307 np);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 308
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 309 cascade_virq = irq_of_parse_and_map(np, 0);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 310
ec775d0e70eb6b arch/powerpc/sysdev/uic.c Thomas Gleixner 2011-03-25 311 irq_set_handler_data(cascade_virq, uic);
ec775d0e70eb6b arch/powerpc/sysdev/uic.c Thomas Gleixner 2011-03-25 312 irq_set_chained_handler(cascade_virq, uic_irq_cascade);
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 313
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 314 /* FIXME: setup critical cascade?? */
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 315 }
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 316 }
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 317 }
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 318
ef24ba7091517d arch/powerpc/sysdev/uic.c Michael Ellerman 2016-09-06 319 /* Return an interrupt vector or 0 if no interrupt is pending. */
e58923ed14370e arch/powerpc/sysdev/uic.c David Gibson 2007-04-18 @320 unsigned int uic_get_irq(void)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36177 bytes --]
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Bjorn Helgaas @ 2020-12-09 21:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, rjui, f.fainelli, linux-rpi-kernel,
Jonathan.Cameron, bhelgaas, jonathan.derrick, sbranden, wangzhou1,
Michael Walle, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <20201209212017.vx7dps3jasjcwg6j@skbuf>
On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > Yep, that's the theory. Thanks for testing it!
>
> Testing what? I'm not following.
You posted a patch that you said fixed the bug for you. The fix is
exactly the theory we've been discussing, so you have already verified
that the theory is correct.
I'm sure Krzysztof will update his patch, and we'll get this tidied up
in -next again.
Bjorn
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Vladimir Oltean @ 2020-12-09 21:43 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, rjui, f.fainelli, linux-rpi-kernel,
Jonathan.Cameron, bhelgaas, jonathan.derrick, sbranden, wangzhou1,
Michael Walle, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <20201209213449.GA2546712@bjorn-Precision-5520>
On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote:
> On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > > Yep, that's the theory. Thanks for testing it!
> >
> > Testing what? I'm not following.
>
> You posted a patch that you said fixed the bug for you. The fix is
> exactly the theory we've been discussing, so you have already verified
> that the theory is correct.
>
> I'm sure Krzysztof will update his patch, and we'll get this tidied up
> in -next again.
If you were discussing this already, I missed it. I was copied to this
thread out of the blue two emails ago. I also looked at the full thread
on patchwork, I don't see anything being said about the culprit being
the size of the config space mapping.
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Bjorn Helgaas @ 2020-12-09 22:05 UTC (permalink / raw)
To: Vladimir Oltean
Cc: kw, heiko, shawn.lin, Alexandru Marginean, paulus,
thomas.petazzoni, jonnyc, toan, will, robh, lorenzo.pieralisi,
michal.simek, linux-rockchip, bcm-kernel-feedback-list,
linux-arm-kernel, linux-pci, rjui, f.fainelli, linux-rpi-kernel,
Jonathan.Cameron, bhelgaas, jonathan.derrick, sbranden, wangzhou1,
Michael Walle, rrichter, linuxppc-dev, nsaenzjulienne
In-Reply-To: <20201209214359.gt4wisqh65oscd4i@skbuf>
On Wed, Dec 09, 2020 at 11:43:59PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote:
> > On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> > > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > > > Yep, that's the theory. Thanks for testing it!
> > >
> > > Testing what? I'm not following.
> >
> > You posted a patch that you said fixed the bug for you. The fix is
> > exactly the theory we've been discussing, so you have already verified
> > that the theory is correct.
> >
> > I'm sure Krzysztof will update his patch, and we'll get this tidied up
> > in -next again.
>
> If you were discussing this already, I missed it. I was copied to this
> thread out of the blue two emails ago. I also looked at the full thread
> on patchwork, I don't see anything being said about the culprit being
> the size of the config space mapping.
Oh, sorry, this was an IRC discussion on #linux-pci (OFTC):
10:51 AM <bjorn_> so the fault is on the first read for 00:00.1. forget my noise about extracting the device/func from the *virtual* address. the *physical* address is supposed to be aligned so you can do that, but not the virtual address
10:55 AM <bjorn_> kwilczynski: oh, i think i see it: pci_ecam_create() does "bsz = 1 << ops->bus_shift", but we removed .bus_shift for this case
10:55 AM <bjorn_> needs to default to 20 if it's not specified
10:56 AM <bjorn_> result is that we only map one page of the ECAM space, so we fault when we access the second page (which is where 00:00.1 starts)
Anyway, thanks very much again for fixing this and confirming the fix!
Bjorn
^ permalink raw reply
* Re: [PATCH v2 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: kernel test robot @ 2020-12-09 23:58 UTC (permalink / raw)
To: Gautham R. Shenoy, Srikar Dronamraju, Anton Blanchard,
Vaidyanathan Srinivasan, Michael Ellerman, Michael Neuling,
Nicholas Piggin, Nathan Lynch, Peter Zijlstra, Valentin Schneider
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <1607533700-5546-6-git-send-email-ego@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 10557 bytes --]
Hi "Gautham,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.10-rc7 next-20201209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-r031-20201209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1968804ac726e7674d5de22bc2204b45857da344)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# https://github.com/0day-ci/linux/commit/61bd9b188793d5009b5cdf310149e498264e6d57
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
git checkout 61bd9b188793d5009b5cdf310149e498264e6d57
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:125:1: note: expanded from here
__do_insb
^
arch/powerpc/include/asm/io.h:556:56: note: expanded from macro '__do_insb'
#define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/cacheinfo.c:21:
In file included from arch/powerpc/include/asm/prom.h:21:
In file included from include/linux/of_address.h:7:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:127:1: note: expanded from here
__do_insw
^
arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw'
#define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/cacheinfo.c:21:
In file included from arch/powerpc/include/asm/prom.h:21:
In file included from include/linux/of_address.h:7:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:129:1: note: expanded from here
__do_insl
^
arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl'
#define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/cacheinfo.c:21:
In file included from arch/powerpc/include/asm/prom.h:21:
In file included from include/linux/of_address.h:7:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:131:1: note: expanded from here
__do_outsb
^
arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb'
#define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/cacheinfo.c:21:
In file included from arch/powerpc/include/asm/prom.h:21:
In file included from include/linux/of_address.h:7:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:133:1: note: expanded from here
__do_outsw
^
arch/powerpc/include/asm/io.h:560:58: note: expanded from macro '__do_outsw'
#define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/cacheinfo.c:21:
In file included from arch/powerpc/include/asm/prom.h:21:
In file included from include/linux/of_address.h:7:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:135:1: note: expanded from here
__do_outsl
^
arch/powerpc/include/asm/io.h:561:58: note: expanded from macro '__do_outsl'
#define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
arch/powerpc/kernel/cacheinfo.c:679:28: error: use of undeclared identifier 'thread_group_shares_l2'; did you mean 'thread_group_leader'?
if (cache->level == 2 && thread_group_shares_l2)
^~~~~~~~~~~~~~~~~~~~~~
thread_group_leader
include/linux/sched/signal.h:652:20: note: 'thread_group_leader' declared here
static inline bool thread_group_leader(struct task_struct *p)
^
>> arch/powerpc/kernel/cacheinfo.c:679:28: warning: address of function 'thread_group_leader' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (cache->level == 2 && thread_group_shares_l2)
~~ ^~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/cacheinfo.c:679:28: note: prefix with the address-of operator to silence this warning
if (cache->level == 2 && thread_group_shares_l2)
^
&
arch/powerpc/kernel/cacheinfo.c:680:11: error: implicit declaration of function 'cpu_l2_cache_mask' [-Werror,-Wimplicit-function-declaration]
return cpu_l2_cache_mask(cpu);
^
>> arch/powerpc/kernel/cacheinfo.c:680:11: warning: incompatible integer to pointer conversion returning 'int' from a function with result type 'const struct cpumask *' [-Wint-conversion]
return cpu_l2_cache_mask(cpu);
^~~~~~~~~~~~~~~~~~~~~~
14 warnings and 2 errors generated.
vim +679 arch/powerpc/kernel/cacheinfo.c
655
656 /*
657 * On big-core systems, each core has two groups of CPUs each of which
658 * has its own L1-cache. The thread-siblings which share l1-cache with
659 * @cpu can be obtained via cpu_smallcore_mask().
660 *
661 * On some big-core systems, the L2 cache is shared only between some
662 * groups of siblings. This is already parsed and encoded in
663 * cpu_l2_cache_mask().
664 *
665 * TODO: cache_lookup_or_instantiate() needs to be made aware of the
666 * "ibm,thread-groups" property so that cache->shared_cpu_map
667 * reflects the correct siblings on platforms that have this
668 * device-tree property. This helper function is only a stop-gap
669 * solution so that we report the correct siblings to the
670 * userspace via sysfs.
671 */
672 static const struct cpumask *get_shared_cpu_map(struct cache_index_dir *index, struct cache *cache)
673 {
674 #ifdef CONFIG_PPC64
675 if (has_big_cores) {
676 int cpu = index_dir_to_cpu(index);
677 if (cache->level == 1)
678 return cpu_smallcore_mask(cpu);
> 679 if (cache->level == 2 && thread_group_shares_l2)
> 680 return cpu_l2_cache_mask(cpu);
681 }
682 #endif
683
684 return &cache->shared_cpu_map;
685 }
686
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37110 bytes --]
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm tree
From: Michael Ellerman @ 2020-12-10 0:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kees Cook, Mathieu Malaterre, Linux Kernel Mailing List,
Nicholas Piggin, Linux Next Mailing List, Andrew Morton, PowerPC
In-Reply-To: <20201209180703.404eb4cb@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Michael,
>
> On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> They should really be in DATA_DATA or similar shouldn't they?
>
> No other architecture appears t need them ...
Any arch with orphan-handling=warn should see them I thought?
cheers
^ permalink raw reply
* Re: [PATCH v1 2/6] powerpc/8xx: Always pin kernel text TLB
From: Michael Ellerman @ 2020-12-10 0:21 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a726961f-f440-b553-6c46-341a860dc90a@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 09/12/2020 à 11:43, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> There is no big poing in not pinning kernel text anymore, as now
>>> we can keep pinned TLB even with things like DEBUG_PAGEALLOC.
>>>
>>> Remove CONFIG_PIN_TLB_TEXT, making it always right.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>> arch/powerpc/Kconfig | 3 +--
>>> arch/powerpc/kernel/head_8xx.S | 20 +++-----------------
>>> arch/powerpc/mm/nohash/8xx.c | 3 +--
>>> arch/powerpc/platforms/8xx/Kconfig | 7 -------
>>> 4 files changed, 5 insertions(+), 28 deletions(-)
>>>
>> ...
>>> diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c
>>> index 231ca95f9ffb..19a3eec1d8c5 100644
>>> --- a/arch/powerpc/mm/nohash/8xx.c
>>> +++ b/arch/powerpc/mm/nohash/8xx.c
>>> @@ -186,8 +186,7 @@ void mmu_mark_initmem_nx(void)
>>> mmu_mapin_ram_chunk(0, boundary, PAGE_KERNEL_TEXT, false);
>>> mmu_mapin_ram_chunk(boundary, einittext8, PAGE_KERNEL, false);
>>>
>>> - if (IS_ENABLED(CONFIG_PIN_TLB_TEXT))
>>> - mmu_pin_tlb(block_mapped_ram, false);
>>> + mmu_pin_tlb(block_mapped_ram, false);
>>> }
>>
>> This broke mpc885_ads_defconfig with:
>
> :surprise:
>
> How did I get it working ? Anyway, thanks for fixing it.
No worries. I figured you must have tested with some other series(s)
applied and/or with different configs, it happens :)
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
From: Michael Ellerman @ 2020-12-10 0:23 UTC (permalink / raw)
To: akpm, hch, Michael Ellerman, Christophe Leroy, viro,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <18bcb456d32a3e74f5ae241fd6f1580c092d07f5.1607360230.git.christophe.leroy@csgroup.eu>
On Mon, 7 Dec 2020 16:58:01 +0000 (UTC), Christophe Leroy wrote:
> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
> routines"), userspace access is not granted anymore when using
> copy_from_kernel_nofault()
>
> However, kthread_probe_data() uses copy_from_kernel_nofault()
> to check validity of pointers. When the pointer is NULL,
> it points to userspace, leading to a KUAP fault and triggering
> the following big hammer warning many times when you request
> a sysrq "show task":
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
https://git.kernel.org/powerpc/c/5eedf9fe8db23313df104576845cec5f481b9b60
cheers
^ permalink raw reply
* Re: [PATCH v2 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: kernel test robot @ 2020-12-10 0:57 UTC (permalink / raw)
To: Gautham R. Shenoy, Srikar Dronamraju, Anton Blanchard,
Vaidyanathan Srinivasan, Michael Ellerman, Michael Neuling,
Nicholas Piggin, Nathan Lynch, Peter Zijlstra, Valentin Schneider
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <1607533700-5546-5-git-send-email-ego@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 10510 bytes --]
Hi "Gautham,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.10-rc7 next-20201209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-r003-20201209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1968804ac726e7674d5de22bc2204b45857da344)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# https://github.com/0day-ci/linux/commit/61bc65c11bf36fdc3827c6d6f4f555fba5306bd9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
git checkout 61bc65c11bf36fdc3827c6d6f4f555fba5306bd9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:164:1: note: expanded from here
__do_insw
^
arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw'
#define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:47:1: error: performing pointer arithmetic on a null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:166:1: note: expanded from here
__do_insl
^
arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl'
#define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:49:1: error: performing pointer arithmetic on a null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:168:1: note: expanded from here
__do_outsb
^
arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb'
#define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:51:1: error: performing pointer arithmetic on a null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:170:1: note: expanded from here
__do_outsw
^
arch/powerpc/include/asm/io.h:560:58: note: expanded from macro '__do_outsw'
#define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:53:1: error: performing pointer arithmetic on a null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:172:1: note: expanded from here
__do_outsl
^
arch/powerpc/include/asm/io.h:561:58: note: expanded from macro '__do_outsl'
#define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
arch/powerpc/kernel/smp.c:569:6: error: no previous prototype for function 'tick_broadcast' [-Werror,-Wmissing-prototypes]
void tick_broadcast(const struct cpumask *mask)
^
arch/powerpc/kernel/smp.c:569:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void tick_broadcast(const struct cpumask *mask)
^
static
arch/powerpc/kernel/smp.c:579:6: error: no previous prototype for function 'debugger_ipi_callback' [-Werror,-Wmissing-prototypes]
void debugger_ipi_callback(struct pt_regs *regs)
^
arch/powerpc/kernel/smp.c:579:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void debugger_ipi_callback(struct pt_regs *regs)
^
static
>> arch/powerpc/kernel/smp.c:905:11: error: variable 'mask' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
else if (cache_property == THREAD_GROUP_SHARE_L2)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/smp.c:908:26: note: uninitialized use occurs here
zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
^~~~
arch/powerpc/kernel/smp.c:905:7: note: remove the 'if' if its condition is always true
else if (cache_property == THREAD_GROUP_SHARE_L2)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/smp.c:886:21: note: initialize the variable 'mask' to silence this warning
cpumask_var_t *mask;
^
= NULL
arch/powerpc/kernel/smp.c:1560:5: error: no previous prototype for function 'setup_profiling_timer' [-Werror,-Wmissing-prototypes]
int setup_profiling_timer(unsigned int multiplier)
^
arch/powerpc/kernel/smp.c:1560:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int setup_profiling_timer(unsigned int multiplier)
^
static
16 errors generated.
vim +905 arch/powerpc/kernel/smp.c
881
882 {
883 int first_thread = cpu_first_thread_sibling(cpu);
884 int i, cpu_group_start = -1, err = 0;
885 struct thread_groups *tg = NULL;
886 cpumask_var_t *mask;
887
888 if (cache_property != THREAD_GROUP_SHARE_L1 &&
889 cache_property != THREAD_GROUP_SHARE_L2)
890 return -EINVAL;
891
892 tg = get_thread_groups(cpu, cache_property, &err);
893 if (!tg)
894 return err;
895
896 cpu_group_start = get_cpu_thread_group_start(cpu, tg);
897
898 if (unlikely(cpu_group_start == -1)) {
899 WARN_ON_ONCE(1);
900 return -ENODATA;
901 }
902
903 if (cache_property == THREAD_GROUP_SHARE_L1)
904 mask = &per_cpu(thread_group_l1_cache_map, cpu);
> 905 else if (cache_property == THREAD_GROUP_SHARE_L2)
906 mask = &per_cpu(thread_group_l2_cache_map, cpu);
907
908 zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
909
910 for (i = first_thread; i < first_thread + threads_per_core; i++) {
911 int i_group_start = get_cpu_thread_group_start(i, tg);
912
913 if (unlikely(i_group_start == -1)) {
914 WARN_ON_ONCE(1);
915 return -ENODATA;
916 }
917
918 if (i_group_start == cpu_group_start)
919 cpumask_set_cpu(i, *mask);
920 }
921
922 return 0;
923 }
924
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28213 bytes --]
^ permalink raw reply
* Re: [PATCH 01/20] ethernet: ucc_geth: set dev->max_mtu to 1518
From: Andrew Lunn @ 2020-12-10 1:25 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Florian Fainelli, Vladimir Oltean, linux-kernel,
Murali Krishna Policharla, netdev, Jakub Kicinski, Li Yang,
linuxppc-dev, David S. Miller, Zhao Qiang
In-Reply-To: <20201205191744.7847-2-rasmus.villemoes@prevas.dk>
On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> All the buffers and registers are already set up appropriately for an
> MTU slightly above 1500, so we just need to expose this to the
> networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> when the receive buffers are always set up to support the max_mtu.
>
> This fixes several warnings during boot on our mpc8309-board with an
> embedded mv88e6250 switch:
>
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> ...
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
>
> The last line explains what the DSA stack tries to do: achieving an MTU
> of 1500 on-the-wire requires that the master netdevice connected to
> the CPU port supports an MTU of 1500+the tagging overhead.
>
> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 07/20] ethernet: ucc_geth: use qe_muram_free_addr()
From: Andrew Lunn @ 2020-12-10 1:36 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Vladimir Oltean, linux-kernel, Li Yang, netdev, Jakub Kicinski,
linuxppc-dev, David S. Miller, Zhao Qiang
In-Reply-To: <20201205191744.7847-8-rasmus.villemoes@prevas.dk>
On Sat, Dec 05, 2020 at 08:17:30PM +0100, Rasmus Villemoes wrote:
> This removes the explicit NULL checks, and allows us to stop storing
> at least some of the _offset values separately.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
This seems to rely on one of the missing patches. Please don't split
patches like this, it makes review very difficult.
Andrew
^ permalink raw reply
* Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
From: Rob Herring @ 2020-12-10 3:23 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Kevin Hilman,
Krzysztof Kozlowski, Ahmad Zainie, Andy Gross, Chunfeng Yun,
linux-snps-arc, devicetree, Mathias Nyman, Martin Blumenstingl,
Lad Prabhakar, Alexey Malahov, Rob Herring, linux-arm-kernel,
Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201205152427.29537-2-Sergey.Semin@baikalelectronics.ru>
On Sat, 05 Dec 2020 18:24:08 +0300, Serge Semin wrote:
> There can be three distinctive types of the USB controllers: USB hosts,
> USB peripherals/gadgets and USB OTG, which can switch from one role to
> another. In order to have that hierarchy handled in the DT binding files,
> we need to collect common properties in a common DT schema and specific
> properties in dedicated schemas. Seeing the usb-hcd.yaml DT schema is
> dedicated for the USB host controllers only, let's move some common
> properties from there into the usb.yaml schema. So the later would be
> available to evaluate all currently supported types of the USB
> controllers.
>
> While at it add an explicit "additionalProperties: true" into the
> usb-hcd.yaml as setting the additionalProperties/unevaluateProperties
> properties is going to be get mandatory soon.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v4:
> - This is a new patch created as a result of the comment left
> by Chunfeng Yun in v3
>
> Changelog v5:
> - Discard duplicated additionalProperties property definition.
> ---
> .../devicetree/bindings/usb/usb-hcd.yaml | 14 ++-------
> .../devicetree/bindings/usb/usb.yaml | 29 +++++++++++++++++++
> 2 files changed, 31 insertions(+), 12 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/usb.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 12/19] dt-bindings: usb: dwc3: Add synopsys, dwc3 compatible string
From: Rob Herring @ 2020-12-10 3:24 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Kevin Hilman,
Krzysztof Kozlowski, Ahmad Zainie, Andy Gross, Chunfeng Yun,
linux-snps-arc, devicetree, Mathias Nyman, Martin Blumenstingl,
Lad Prabhakar, Alexey Malahov, Rob Herring, linux-arm-kernel,
Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201205152427.29537-13-Sergey.Semin@baikalelectronics.ru>
On Sat, 05 Dec 2020 18:24:19 +0300, Serge Semin wrote:
> The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc
> expects the DWC USB3 DT node to have the compatible string with the
> "synopsys" vendor prefix. Let's add the corresponding compatible string to
> the controller DT schema, but mark it as deprecated seeing the Synopsys,
> Inc. is presented with just "snps" vendor prefix.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Drop quotes from around the compat string constant.
>
> Changelog v4:
> - Get the patch back, since we can't discard the deprecated prefix from the
> driver.
> ---
> Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
From: Bharata B Rao @ 2020-12-10 4:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: aneesh.kumar, npiggin, kvm-ppc, linuxppc-dev, David Gibson
In-Reply-To: <20201209041542.GA29825@thinks.paulus.ozlabs.org>
On Wed, Dec 09, 2020 at 03:15:42PM +1100, Paul Mackerras wrote:
> On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote:
> > Implements H_RPT_INVALIDATE hcall and supports only nested case
> > currently.
> >
> > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the
> > support for this hcall.
>
> I have a couple of questions about this patch:
>
> 1. Is this something that is useful today, or is it something that may
> become useful in the future depending on future product plans? In
> other words, what advantage is there to forcing L2 guests to use this
> hcall instead of doing tlbie themselves?
H_RPT_INVALIDATE will replace the use of the existing H_TLB_INVALIDATE
for nested partition scoped invalidations. Implementations that want to
off-load invalidations to the host (when GTSE=0) would have to bother
about only one hcall (H_RPT_INVALIDATE)
>
> 2. Why does it need to be added to the default-enabled hcall list?
>
> There is a concern that if this is enabled by default we could get the
> situation where a guest using it gets migrated to a host that doesn't
> support it, which would be bad. That is the reason that all new
> things like this are disabled by default and only enabled by userspace
> (i.e. QEMU) in situations where we can enforce that it is available on
> all hosts to which the VM might be migrated.
As you suggested privately, I am thinking of falling back to
H_TLB_INVALIDATE in case where this new hcall fails due to not being
present. That should address the migration case that you mention
above. With that and leaving the new hcall enabled by default
is good okay?
Regards,
Bharata.
^ permalink raw reply
* Re: [PATCH v2 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: kernel test robot @ 2020-12-10 4:30 UTC (permalink / raw)
To: Gautham R. Shenoy, Srikar Dronamraju, Anton Blanchard,
Vaidyanathan Srinivasan, Michael Ellerman, Michael Neuling,
Nicholas Piggin, Nathan Lynch, Peter Zijlstra, Valentin Schneider
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <1607533700-5546-5-git-send-email-ego@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 10071 bytes --]
Hi "Gautham,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.10-rc7 next-20201209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-r035-20201209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1968804ac726e7674d5de22bc2204b45857da344)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# https://github.com/0day-ci/linux/commit/61bc65c11bf36fdc3827c6d6f4f555fba5306bd9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Gautham-R-Shenoy/Extend-Parsing-ibm-thread-groups-for-Shared-L2-information/20201210-011226
git checkout 61bc65c11bf36fdc3827c6d6f4f555fba5306bd9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:233:1: note: expanded from here
__do_insw
^
arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw'
#define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:235:1: note: expanded from here
__do_insl
^
arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl'
#define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:2:1: note: expanded from here
__do_outsb
^
arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb'
#define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:4:1: note: expanded from here
__do_outsw
^
arch/powerpc/include/asm/io.h:560:58: note: expanded from macro '__do_outsw'
#define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/smp.c:22:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:10:
In file included from arch/powerpc/include/asm/hardirq.h:6:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/powerpc/include/asm/io.h:619:
arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; \
^~~~~~~~~~~~~~
<scratch space>:6:1: note: expanded from here
__do_outsl
^
arch/powerpc/include/asm/io.h:561:58: note: expanded from macro '__do_outsl'
#define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
~~~~~~~~~~~~~~~~~~~~~^
arch/powerpc/kernel/smp.c:569:6: warning: no previous prototype for function 'tick_broadcast' [-Wmissing-prototypes]
void tick_broadcast(const struct cpumask *mask)
^
arch/powerpc/kernel/smp.c:569:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void tick_broadcast(const struct cpumask *mask)
^
static
arch/powerpc/kernel/smp.c:579:6: warning: no previous prototype for function 'debugger_ipi_callback' [-Wmissing-prototypes]
void debugger_ipi_callback(struct pt_regs *regs)
^
arch/powerpc/kernel/smp.c:579:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void debugger_ipi_callback(struct pt_regs *regs)
^
static
>> arch/powerpc/kernel/smp.c:905:11: warning: variable 'mask' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
else if (cache_property == THREAD_GROUP_SHARE_L2)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/smp.c:908:26: note: uninitialized use occurs here
zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
^~~~
arch/powerpc/kernel/smp.c:905:7: note: remove the 'if' if its condition is always true
else if (cache_property == THREAD_GROUP_SHARE_L2)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/smp.c:886:21: note: initialize the variable 'mask' to silence this warning
cpumask_var_t *mask;
^
= NULL
15 warnings generated.
vim +905 arch/powerpc/kernel/smp.c
881
882 {
883 int first_thread = cpu_first_thread_sibling(cpu);
884 int i, cpu_group_start = -1, err = 0;
885 struct thread_groups *tg = NULL;
886 cpumask_var_t *mask;
887
888 if (cache_property != THREAD_GROUP_SHARE_L1 &&
889 cache_property != THREAD_GROUP_SHARE_L2)
890 return -EINVAL;
891
892 tg = get_thread_groups(cpu, cache_property, &err);
893 if (!tg)
894 return err;
895
896 cpu_group_start = get_cpu_thread_group_start(cpu, tg);
897
898 if (unlikely(cpu_group_start == -1)) {
899 WARN_ON_ONCE(1);
900 return -ENODATA;
901 }
902
903 if (cache_property == THREAD_GROUP_SHARE_L1)
904 mask = &per_cpu(thread_group_l1_cache_map, cpu);
> 905 else if (cache_property == THREAD_GROUP_SHARE_L2)
906 mask = &per_cpu(thread_group_l2_cache_map, cpu);
907
908 zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
909
910 for (i = first_thread; i < first_thread + threads_per_core; i++) {
911 int i_group_start = get_cpu_thread_group_start(i, tg);
912
913 if (unlikely(i_group_start == -1)) {
914 WARN_ON_ONCE(1);
915 return -ENODATA;
916 }
917
918 if (i_group_start == cpu_group_start)
919 cpumask_set_cpu(i, *mask);
920 }
921
922 return 0;
923 }
924
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27079 bytes --]
^ permalink raw reply
* Re: [PATCH 00/20] ethernet: ucc_geth: assorted fixes and simplifications
From: Rasmus Villemoes @ 2020-12-10 7:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kernel, Li Yang, Vladimir Oltean, linuxppc-dev,
David S. Miller, linux-arm-kernel, Qiang Zhao
In-Reply-To: <20201205132716.4c68e35d@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
On 05/12/2020 22.27, Jakub Kicinski wrote:
> On Sat, 5 Dec 2020 22:11:39 +0100 Rasmus Villemoes wrote:
>>> Looks like a nice clean up on a quick look.
>>>
>>> Please separate patches 1 and 11 (which are the two bug fixes I see)
>>
>> I think patch 2 is a bug fix as well, but I'd like someone from NXP to
>> comment.
>
> Sure, makes sense.
>
>>> rebase (retest) and post them against the net tree:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/
>>
>> So I thought this would go through Li Yang's tree.
Li, any preference? Will you take this series, or are you ok with the
three soc/fsl/qe patches going through the net tree along with the rest?
Rasmus
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
From: Geert Uytterhoeven @ 2020-12-10 9:06 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Peter Zijlstra, Aneesh Kumar K.V, Linux Kernel Mailing List,
Anton Vorontsov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201120025757.325930-3-npiggin@gmail.com>
Hi Nicholas,
On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>
> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
> to manage its TLBs.
>
> However the exit_flush_lazy_tlbs() function expects that after
> returning, all CPUs (except self) have flushed TLBs for that mm, in
> which case TLBIEL can be used for this flush. This breaks for offline
> CPUs because they don't get the IPI to flush their TLB. This can lead
> to stale translations.
>
> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
> before going offline.
>
> These offlined CPU bits stuck in the cpumask also prevents the cpumask
> from being trimmed back to local mode, which means continual broadcast
> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
> situation too.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Thanks for your patch!
> --- a/arch/powerpc/platforms/powermac/smp.c
> +++ b/arch/powerpc/platforms/powermac/smp.c
> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>
> mpic_cpu_set_priority(0xf);
>
> + cleanup_cpu_mmu_context();
> +
I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
arch/powerpc/platforms/powermac/smp.c: error: implicit
declaration of function 'cleanup_cpu_mmu_context'
[-Werror=implicit-function-declaration]: => 914:2
http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> index 54c4ba45c7ce..cbb67813cd5d 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -143,6 +143,9 @@ static int pnv_smp_cpu_disable(void)
> xive_smp_disable_cpu();
> else
> xics_migrate_irqs_away();
> +
> + cleanup_cpu_mmu_context();
> +
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index f2837e33bf5d..a02012f1b04a 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -90,6 +90,9 @@ static int pseries_cpu_disable(void)
> xive_smp_disable_cpu();
> else
> xics_migrate_irqs_away();
> +
> + cleanup_cpu_mmu_context();
> +
> return 0;
> }
>
> --
> 2.23.0
>
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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