* Re: [PATCH v5 19/19] dt-bindings: usb: intel, keembay-dwc3: Validate DWC3 sub-node
From: Rob Herring @ 2020-12-07 16:53 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-20-Sergey.Semin@baikalelectronics.ru>
On Sat, 05 Dec 2020 18:24:26 +0300, Serge Semin wrote:
> Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
> compatible sub-node to describe a fully functioning USB interface. Let's
> use the available DWC USB3 DT schema to validate the Qualcomm DWC3
> sub-nodes.
>
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v5:
> - This is a new patch created for the new Intel Keem Bay bindings file,
> which has been added just recently.
> ---
> .../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 01/19] dt-bindings: usb: usb-hcd: Detach generic USB controller properties
From: Rob Herring @ 2020-12-07 16:50 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, linux-mips, 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, Bjorn Andersson,
linux-arm-kernel, Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-kernel, Serge Semin,
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
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml: 'anyOf' conditional failed, one must be fixed:
'properties' is a required property
'patternProperties' is a required property
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/usb-hcd.yaml: ignoring, error in schema:
warning: no schema found in file: ./Documentation/devicetree/bindings/usb/usb-hcd.yaml
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
dt-validate: recursion error: Check for prior errors in a referenced schema
schemas/usb/usb-hcd.yaml: ignoring, error in schema:
dt-validate: recursion error: Check for prior errors in a referenced schema
dt-validate: recursion error: Check for prior errors in a referenced schema
See https://patchwork.ozlabs.org/patch/1411574
The base for the patch is generally the last rc1. Any dependencies
should be noted.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
From: Rob Herring @ 2020-12-07 16:49 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, linux-mips, 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, Bjorn Andersson,
linux-arm-kernel, Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-kernel, Serge Semin,
Manu Gautam, linuxppc-dev
In-Reply-To: <20201205152427.29537-11-Sergey.Semin@baikalelectronics.ru>
On Sat, 05 Dec 2020 18:24:17 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
>
> Note 1. we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
>
> Note 2. The clock-related properties are marked as optional to match the
> DWC USB3 driver expectation and to improve the bindings mainainability
> so in case if there is a glue-node it would the responsible for the
> clocks initialization.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
> the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
> clock-names instead of the ones from the Databook.
>
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
> as either host or otg.
>
> Changelog v4:
> - Apply usb-drd.yaml schema first. If the controller is configured
> to work in a gadget mode only, then apply the usb.yaml schema too,
> otherwise apply the usb-xhci.yaml schema.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more
> time.
>
> Changelog v5:
> - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema.
> - Add a commit log text about the clock-related property changes.
> - Make sure dr_mode exist to apply the USB-gadget-only schema.
> ---
> .../devicetree/bindings/usb/dwc3.txt | 128 -------
> .../devicetree/bindings/usb/snps,dwc3.yaml | 312 ++++++++++++++++++
> 2 files changed, 312 insertions(+), 128 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:55:4: [warning] wrong indentation: expected 4 but found 3 (indentation)
dtschema/dtc warnings/errors:
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/usb/usb-drd.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 124
make: *** [Makefile:1364: dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1411582
The base for the patch is generally the last rc1. Any dependencies
should be noted.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
^ permalink raw reply
* [PATCH] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected"
From: Colin King @ 2020-12-07 15:54 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in the help text of the Kconfig. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8fb61a285c76..4010bae52351 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -87,7 +87,7 @@ config PPC_WATCHDOG
help
This is a placeholder when the powerpc hardlockup detector
watchdog is selected (arch/powerpc/kernel/watchdog.c). It is
- seleted via the generic lockup detector menu which is why we
+ selected via the generic lockup detector menu which is why we
have no standalone config option for it here.
config STACKTRACE_SUPPORT
--
2.29.2
^ permalink raw reply related
* [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
From: Enrico Weigelt, metux IT consult @ 2020-12-07 14:31 UTC (permalink / raw)
To: linux-kernel
Cc: linux-s390, hpa, linux-parisc, deller, x86, linux-um,
James.Bottomley, mingo, paulus, richard, bp, tglx, linuxppc-dev,
jdike, anton.ivanov
All archs, except Alpha, print out the irq number in hex, but the message
looks like it was a decimal number, which is quite confusing. Fixing this
by adding "0x" prefix.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
arch/arm/include/asm/hw_irq.h | 2 +-
arch/parisc/include/asm/hardirq.h | 2 +-
arch/powerpc/include/asm/hardirq.h | 2 +-
arch/s390/include/asm/hardirq.h | 2 +-
arch/um/include/asm/hardirq.h | 2 +-
arch/x86/kernel/irq.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
index cecc13214ef1..2749f19271d9 100644
--- a/arch/arm/include/asm/hw_irq.h
+++ b/arch/arm/include/asm/hw_irq.h
@@ -9,7 +9,7 @@ static inline void ack_bad_irq(int irq)
{
extern unsigned long irq_err_count;
irq_err_count++;
- pr_crit("unexpected IRQ trap at vector %02x\n", irq);
+ pr_crit("unexpected IRQ trap at vector 0x%02x\n", irq);
}
#define ARCH_IRQ_INIT_FLAGS (IRQ_NOREQUEST | IRQ_NOPROBE)
diff --git a/arch/parisc/include/asm/hardirq.h b/arch/parisc/include/asm/hardirq.h
index 7f7039516e53..c3348af88d3f 100644
--- a/arch/parisc/include/asm/hardirq.h
+++ b/arch/parisc/include/asm/hardirq.h
@@ -35,6 +35,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
#define __IRQ_STAT(cpu, member) (irq_stat[cpu].member)
#define inc_irq_stat(member) this_cpu_inc(irq_stat.member)
#define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member)
-#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", irq)
+#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector 0x%02x\n", irq)
#endif /* _PARISC_HARDIRQ_H */
diff --git a/arch/powerpc/include/asm/hardirq.h b/arch/powerpc/include/asm/hardirq.h
index f133b5930ae1..ec8cf3cf6e49 100644
--- a/arch/powerpc/include/asm/hardirq.h
+++ b/arch/powerpc/include/asm/hardirq.h
@@ -29,7 +29,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
static inline void ack_bad_irq(unsigned int irq)
{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
+ printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
}
extern u64 arch_irq_stat_cpu(unsigned int cpu);
diff --git a/arch/s390/include/asm/hardirq.h b/arch/s390/include/asm/hardirq.h
index dfbc3c6c0674..aaaec5cdd4fe 100644
--- a/arch/s390/include/asm/hardirq.h
+++ b/arch/s390/include/asm/hardirq.h
@@ -23,7 +23,7 @@
static inline void ack_bad_irq(unsigned int irq)
{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
+ printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
}
#endif /* __ASM_HARDIRQ_H */
diff --git a/arch/um/include/asm/hardirq.h b/arch/um/include/asm/hardirq.h
index b426796d26fd..2a2e6eae034b 100644
--- a/arch/um/include/asm/hardirq.h
+++ b/arch/um/include/asm/hardirq.h
@@ -15,7 +15,7 @@ typedef struct {
#ifndef ack_bad_irq
static inline void ack_bad_irq(unsigned int irq)
{
- printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
+ printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
}
#endif
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index c5dd50369e2f..957c716f2df7 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -37,7 +37,7 @@ atomic_t irq_err_count;
void ack_bad_irq(unsigned int irq)
{
if (printk_ratelimit())
- pr_err("unexpected IRQ trap at vector %02x\n", irq);
+ pr_err("unexpected IRQ trap at vector 0x%02x\n", irq);
/*
* Currently unexpected vectors happen only on SMP and APIC.
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: Srikar Dronamraju @ 2020-12-07 13:11 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607057327-29822-4-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:47]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> +extern bool thread_group_shares_l2;
> /*
> * 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().
> */
> static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
> {
> if (cache->level == 1)
> return cpu_smallcore_mask(cpu);
> + if (cache->level == 2 && thread_group_shares_l2)
> + return cpu_l2_cache_mask(cpu);
>
> return &cache->shared_cpu_map;
As pointed with lkp@intel.org, we need to do this only with #CONFIG_SMP,
even for cache->level = 1 too.
I agree that we are displaying shared_cpu_map correctly. Should we have also
update /clear shared_cpu_map in the first place. For example:- If for a P9
core with CPUs 0-7, the cache->shared_cpu_map for L1 would have 0-7 but
would display 0,2,4,6.
The drawback of this is even if cpus 0,2,4,6 are released L1 cache will not
be released. Is this as expected?
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: Srikar Dronamraju @ 2020-12-07 12:40 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607057327-29822-3-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:46]:
> 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/kernel/smp.c | 66 +++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 58 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 6a242a3..a116d2d 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;
Either keep this as static in this patch or add its declaration
>
> 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, cpu_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);
> +
NIT:
We are trying to confuse ourselves with the names.
For L1 we have cpu_l2_cache_map to store the tasks from the thread group.
but cpu_smallcore_map for keeping track of tasks.
For L2 we have thread_group_l2_cache_map to store the tasks from the thread
group. but cpu_l2_cache_map for keeping track of tasks.
I think we should do some renaming to keep the names consistent.
I would say probably say move the current cpu_l2_cache_map to
cpu_llc_cache_map and move the new aka thread_group_l2_cache_map as
cpu_l2_cache_map to be somewhat consistent.
> /* SMP operations for this machine */
> struct smp_ops_t *smp_ops;
>
> @@ -840,7 +851,8 @@ static int init_cpu_cache_map(int cpu, unsigned int cache_property)
> if (!dn)
> return -ENODATA;
>
> - if (!(cache_property == THREAD_GROUP_SHARE_L1))
> + if (!(cache_property == THREAD_GROUP_SHARE_L1 ||
> + cache_property == THREAD_GROUP_SHARE_L2))
> return -EINVAL;
>
> if (!cpu_tgl->nr_properties) {
> @@ -867,7 +879,10 @@ static int init_cpu_cache_map(int cpu, unsigned int cache_property)
> goto out;
> }
>
> - mask = &per_cpu(cpu_l1_cache_map, cpu);
> + if (cache_property == THREAD_GROUP_SHARE_L1)
> + mask = &per_cpu(cpu_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));
>
> @@ -973,6 +988,16 @@ static int init_big_cores(void)
> }
>
> has_big_cores = true;
> +
> + for_each_possible_cpu(cpu) {
> + int err = init_cpu_cache_map(cpu, THREAD_GROUP_SHARE_L2);
> +
> + if (err)
> + return err;
> + }
> +
> + thread_group_shares_l2 = true;
Why do we need a separate loop. Why cant we merge this in the above loop
itself?
> + pr_info("Thread-groups in a core share L2-cache\n");
Can this be moved to a pr_debug? Does it help any regular user/admins to
know if thread-groups shared l2 cache. Infact it may confuse users on what
thread groups are and which thread groups dont share cache.
I would prefer some other name than thread_group_shares_l2 but dont know any
better alternatives and may be my choices are even worse.
> return 0;
> }
>
> @@ -1287,6 +1312,31 @@ static bool update_mask_by_l2(int cpu, cpumask_var_t *mask)
> if (has_big_cores)
> submask_fn = cpu_smallcore_mask;
>
> +
NIT: extra blank line?
> + /*
> + * 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) {
> + /* Siblings that share L1 is a subset of siblings that share L2.*/
> + or_cpumasks_related(cpu, cpu, submask_fn, cpu_l2_cache_mask);
> + if (*mask) {
> + cpumask_andnot(*mask,
> + per_cpu(thread_group_l2_cache_map, cpu),
> + cpu_l2_cache_mask(cpu));
> + } else {
> + mask = &per_cpu(thread_group_l2_cache_map, cpu);
> + }
> +
> + for_each_cpu(i, *mask) {
> + if (!cpu_online(i))
> + continue;
> + set_cpus_related(i, cpu, cpu_l2_cache_mask);
> + }
> +
> + return true;
> + }
> +
Ah this can be simplified to:
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);
}
}
No?
> l2_cache = cpu_to_l2cache(cpu);
> if (!l2_cache || !*mask) {
> /* Assume only core siblings share cache with this CPU */
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [powerpc:next-test 54/220] arch/powerpc/kernel/vdso32/vgettimeofday.c:13:5: warning: no previous prototype for function '__c_kernel_clock_gettime64'
From: Michael Ellerman @ 2020-12-07 12:23 UTC (permalink / raw)
To: kernel test robot, Christophe Leroy
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <202012042220.zO7hSFT2-lkp@intel.com>
kernel test robot <lkp@intel.com> writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: 4e4ed87981c764498942c52004c620bb8f104eac
> commit: d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e [54/220] powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
> config: powerpc64-randconfig-r011-20201204 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 32c501dd88b62787d3a5ffda7aabcf4650dbe3cd)
> 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://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e
> git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> git fetch --no-tags powerpc next-test
> git checkout d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e
> # 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/kernel/vdso32/vgettimeofday.c:7:5: error: conflicting types for '__c_kernel_clock_gettime'
> int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts,
> ^
We're building vdso32, which is 32-bit code, we pass -m32:
clang -Wp,-MMD,arch/powerpc/kernel/vdso32/.vgettimeofday.o.d -nostdinc -isystem /usr/lib/llvm-11/lib/clang/11.0.0/include -I/linux/arch/powerpc/include -I./arch/powerpc/include/generated -I/linux/include -I./include -I/linux/arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I/linux/include/uapi -I./include/generated/uapi -include /linux/include/linux/kconfig.h -include /linux/include/linux/compiler_types.h -D__KERNEL__ -I /linux/arch/powerpc -DHAVE_AS_ATHIGH=1 -Qunused-arguments -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 --target=powerpc64le-linux-gnu --prefix=/usr/bin/powerpc64le-linux-gnu- --gcc-toolchain=/usr -no-integrated-as -Werror=unknown-warning-option -mlittle-endian -m64 -msoft-float -pipe -mcpu=power8 -mtune=power9 -mno-altivec -mno-vsx -mno-spe -fno-asynchronous-unwind-tables -Wa,-mpower4 -Wa,-many -mlittle-endian -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -Os -Wframe-larger-than=2048 -fno-stack-protector -Wno-format-invalid-specifier -Wno-gnu -mno-global-merge -Wno-unused-const-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -fmacro-prefix-map=/linux/= -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -D_TASK_CPU=304 -shared -fno-common -fno-builtin -nostdlib -Wl,-soname=linux-vdso32.so.1 -Wl,--hash-style=both -include /linux/lib/vdso/gettimeofday.c -fno-stack-protector -DDISABLE_BRANCH_PROFILING -ffreestanding -fasynchronous-unwind-tables -I /linux/arch/powerpc/kernel/vdso32 -I ./arch/powerpc/kernel/vdso32 -DKBUILD_MODFILE='"arch/powerpc/kernel/vdso32/vgettimeofday"' -DKBUILD_BASENAME='"vgettimeofday"' -DKBUILD_MODNAME='"vgettimeofday"' -m32 -c -o arch/powerpc/kernel/vdso32/vgettimeofday.o /linux/arch/powerpc/kernel/vdso32/vgettimeofday.c
> arch/powerpc/include/asm/vdso/gettimeofday.h:183:5: note: previous declaration is here
> int __c_kernel_clock_gettime(clockid_t clock, struct __kernel_timespec *ts,
> ^
But this is inside an #ifdef __powerpc64__ block:
182 #ifdef __powerpc64__
183 int __c_kernel_clock_gettime(clockid_t clock, struct __kernel_timespec *ts,
184 const struct vdso_data *vd);
So is clang defining __powerpc64__ even for 32-bit code?
And the answer appears to be yes:
$ clang --version
Ubuntu clang version 11.0.0-2
Target: powerpc64le-unknown-linux-gnu
$ clang -m32 -dM -E - < /dev/null | grep powerpc
#define __powerpc64__ 1
#define __powerpc__ 1
Compare to gcc:
$ gcc --version
gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0
$ gcc -m32 -dM -E - < /dev/null | grep powerpc
#define __powerpc__ 1
#define powerpc 1
#define __powerpc 1
Which is fairly problematic, because we use the presence/absence of
__powerpc64__ to determine if we're building 64-bit/32-bit code in
several places.
Not sure what the best approach for fixing that is.
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups with multiple properties
From: Srikar Dronamraju @ 2020-12-07 12:10 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607057327-29822-2-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:45]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
<snipped>
>
> 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];
> + int i = 0;
> + u32 *thread_group_array;
> u32 *thread_list;
> size_t total_threads;
> - int ret;
> + int ret = 0, count;
> + unsigned int property_idx = 0;
NIT:
tglx mentions in one of his recent comments to try keep a reverse fir tree
ordering of variables where possible.
>
> + 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++];
NIT: same as above.
>
> - 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[i + 3];
>
> - thread_list = &thread_group_array[3];
> + for (j = 0; j < total_threads; j++)
> + tg->thread_list[j] = thread_list[j];
> + i = i + 3 + total_threads;
Can't we simply use memcpy instead?
> + }
>
> - for (i = 0 ; i < total_threads; i++)
> - tg->thread_list[i] = thread_list[i];
> + tglp->nr_properties = property_idx;
>
> - return 0;
> +out_free:
> + kfree(thread_group_array);
> + return ret;
> }
>
> /*
> @@ -805,24 +827,39 @@ static int get_cpu_thread_group_start(int cpu, struct thread_groups *tg)
> return -1;
> }
>
> -static int init_cpu_l1_cache_map(int cpu)
> +static int init_cpu_cache_map(int cpu, unsigned int cache_property)
>
> {
> struct device_node *dn = of_get_cpu_node(cpu, NULL);
> - struct thread_groups tg = {.property = 0,
> - .nr_groups = 0,
> - .threads_per_group = 0};
> + struct thread_groups *tg = NULL;
> int first_thread = cpu_first_thread_sibling(cpu);
> int i, cpu_group_start = -1, err = 0;
> + cpumask_var_t *mask;
> + struct thread_groups_list *cpu_tgl = &tgl[cpu];
NIT: same as 1st comment.
>
> if (!dn)
> return -ENODATA;
>
> - err = parse_thread_groups(dn, &tg, THREAD_GROUP_SHARE_L1);
> - if (err)
> - goto out;
> + if (!(cache_property == THREAD_GROUP_SHARE_L1))
> + return -EINVAL;
>
> - cpu_group_start = get_cpu_thread_group_start(cpu, &tg);
> + 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 == cache_property) {
> + tg = &cpu_tgl->property_tgs[i];
> + break;
> + }
> + }
> +
> + if (!tg)
> + return -EINVAL;
> +
> + cpu_group_start = get_cpu_thread_group_start(cpu, tg);
This whole hunk should be moved to a new function and called before
init_cpu_cache_map. It will simplify the logic to great extent.
>
> if (unlikely(cpu_group_start == -1)) {
> WARN_ON_ONCE(1);
> @@ -830,11 +867,12 @@ static int init_cpu_l1_cache_map(int cpu)
> goto out;
> }
>
> - zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
> - GFP_KERNEL, cpu_to_node(cpu));
> + mask = &per_cpu(cpu_l1_cache_map, cpu);
> +
> + zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
>
This hunk (and the next hunk) should be moved to next patch.
> 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);
> @@ -843,7 +881,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, *mask);
> }
>
> out:
> @@ -924,7 +962,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_cpu_cache_map(cpu, THREAD_GROUP_SHARE_L1);
>
> if (err)
> return err;
> --
> 1.9.4
>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: Build regressions/improvements in v5.10-rc7
From: Geert Uytterhoeven @ 2020-12-07 12:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20201207120611.1315807-1-geert@linux-m68k.org>
On Mon, Dec 7, 2020 at 1:08 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> JFYI, when comparing v5.10-rc7[1] to v5.10-rc6[3], the summaries are:
> - build errors: +1/-0
+ /kisskb/src/arch/powerpc/platforms/powermac/smp.c: error: implicit
declaration of function 'cleanup_cpu_mmu_context'
[-Werror=implicit-function-declaration]: => 914:2
v5.10-rc7/powerpc-gcc4.9/pmac32_defconfig+SMP
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/0477e92881850d44910a7e94fc2c46f96faa131f/ (all 192 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/b65054597872ce3aefbc6a666385eabdf9e288da/ (all 192 configs)
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
* Re: [PATCH v2 01/17] ibmvfc: add vhost fields and defaults for MQ enablement
From: Hannes Reinecke @ 2020-12-07 11:56 UTC (permalink / raw)
To: Brian King, Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <efbfe9e9-c692-80a1-f5b4-55473d8193e4@linux.vnet.ibm.com>
On 12/4/20 3:26 PM, Brian King wrote:
> On 12/2/20 11:27 AM, Tyrel Datwyler wrote:
>> On 12/2/20 7:14 AM, Brian King wrote:
>>> On 12/1/20 6:53 PM, Tyrel Datwyler wrote:
>>>> Introduce several new vhost fields for managing MQ state of the adapter
>>>> as well as initial defaults for MQ enablement.
>>>>
>>>> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
>>>> ---
>>>> drivers/scsi/ibmvscsi/ibmvfc.c | 9 ++++++++-
>>>> drivers/scsi/ibmvscsi/ibmvfc.h | 13 +++++++++++--
>>>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
>>>> index 42e4d35e0d35..f1d677a7423d 100644
>>>> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
>>>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
>>>> @@ -5161,12 +5161,13 @@ static int ibmvfc_probe(struct vio_dev *vdev, const struct vio_device_id *id)
>>>> }
>>>>
>>>> shost->transportt = ibmvfc_transport_template;
>>>> - shost->can_queue = max_requests;
>>>> + shost->can_queue = (max_requests / IBMVFC_SCSI_HW_QUEUES);
>>>
>>> This doesn't look right. can_queue is the SCSI host queue depth, not the MQ queue depth.
>>
>> Our max_requests is the total number commands allowed across all queues. From
>> what I understand is can_queue is the total number of commands in flight allowed
>> for each hw queue.
>>
>> /*
>> * In scsi-mq mode, the number of hardware queues supported by the LLD.
>> *
>> * Note: it is assumed that each hardware queue has a queue depth of
>> * can_queue. In other words, the total queue depth per host
>> * is nr_hw_queues * can_queue. However, for when host_tagset is set,
>> * the total queue depth is can_queue.
>> */
>>
>> We currently don't use the host wide shared tagset.
>
> Ok. I missed that bit... In that case, since we allocate by default only 100
> event structs. If we slice that across IBMVFC_SCSI_HW_QUEUES (16) queues, then
> we end up with only about 6 commands that can be outstanding per queue,
> which is going to really hurt performance... I'd suggest bumping up
> IBMVFC_MAX_REQUESTS_DEFAULT from 100 to 1000 as a starting point.
>
Before doing that I'd rather use the host-wide shared tagset.
Increasing the number of requests will increase the memory footprint of
the driver (as each request will be statically allocated).
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
^ permalink raw reply
* [Bug 209277] powerpc: obsolete driver: Marvell MV64X60 MPSC
From: bugzilla-daemon @ 2020-12-07 11:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-209277-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=209277
--- Comment #2 from Borislav Petkov (bp@alien8.de) ---
https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git/commit/?h=edac-drivers&id=0385979a30dc4abdef2dcebbccef818947c80cb7
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver
From: Borislav Petkov @ 2020-12-07 11:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: tony.luck, rric, linux-kernel, linuxppc-dev, james.morse, mchehab,
linux-edac
In-Reply-To: <20201207040253.628528-1-mpe@ellerman.id.au>
On Mon, Dec 07, 2020 at 03:02:53PM +1100, Michael Ellerman wrote:
> The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is
> not user-selectable, and the last code that selected it was removed
> with the C2K board support in 2018, see:
>
> 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
>
> That means the driver is now dead code, so remove it.
>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> drivers/edac/Kconfig | 7 -
> drivers/edac/Makefile | 1 -
> drivers/edac/mv64x60_edac.c | 883 ------------------------------------
> drivers/edac/mv64x60_edac.h | 114 -----
> 4 files changed, 1005 deletions(-)
> delete mode 100644 drivers/edac/mv64x60_edac.c
> delete mode 100644 drivers/edac/mv64x60_edac.h
Gladly taken and applied, thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v5 10/19] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
From: Chunfeng Yun @ 2020-12-07 9:35 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Kevin Hilman,
Krzysztof Kozlowski, Ahmad Zainie, Andy Gross, 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-11-Sergey.Semin@baikalelectronics.ru>
On Sat, 2020-12-05 at 18:24 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
>
> Note 1. we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
>
> Note 2. The clock-related properties are marked as optional to match the
> DWC USB3 driver expectation and to improve the bindings mainainability
> so in case if there is a glue-node it would the responsible for the
> clocks initialization.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
> the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
> clock-names instead of the ones from the Databook.
>
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
> as either host or otg.
>
> Changelog v4:
> - Apply usb-drd.yaml schema first. If the controller is configured
> to work in a gadget mode only, then apply the usb.yaml schema too,
> otherwise apply the usb-xhci.yaml schema.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more
> time.
>
> Changelog v5:
> - Add "snps,dis-split-quirk" property to the DWC USB3 DT schema.
> - Add a commit log text about the clock-related property changes.
> - Make sure dr_mode exist to apply the USB-gadget-only schema.
> ---
> .../devicetree/bindings/usb/dwc3.txt | 128 -------
> .../devicetree/bindings/usb/snps,dwc3.yaml | 312 ++++++++++++++++++
> 2 files changed, 312 insertions(+), 128 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> deleted file mode 100644
> index 1aae2b6160c1..000000000000
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ /dev/null
> @@ -1,128 +0,0 @@
> -synopsys DWC3 CORE
> -
[...]
> +
> + clock-names:
> + contains:
> + anyOf:
> + - enum: [bus_early, ref, suspend]
> + - true
> +
> + usb-phy:
> + minItems: 1
indentation: expected 4
> + items:
> + - description: USB2/HS PHY
> + - description: USB3/SS PHY
> +
> + phys:
> + minItems: 1
> + items:
> + - description: USB2/HS PHY
> + - description: USB3/SS PHY
> +
> + phy-names:
> + minItems: 1
> + items:
> + - const: usb2-phy
> + - const: usb3-phy
[...]
^ permalink raw reply
* Re: [PATCH v5 02/19] dt-bindings: usb: Convert generic USB properties to DT schemas
From: Chunfeng Yun @ 2020-12-07 7:37 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Rob Herring,
Kevin Hilman, Krzysztof Kozlowski, Ahmad Zainie, Andy Gross,
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-3-Sergey.Semin@baikalelectronics.ru>
On Sat, 2020-12-05 at 18:24 +0300, Serge Semin wrote:
> The generic USB properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert its content into the generic USB, USB HCD and USB DRD DT
> schemas. So the Generic USB schema will be applicable to all USB
> controllers, USB HCD - for the generic USB Host controllers and the USB
> DRD - for the USB Dual-role controllers.
>
> Note the USB DRD schema is supposed to work in conjunction with
> the USB peripheral/gadget and USB host controllers DT schemas.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> ---
>
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
> the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
> the multi-lined version of the list.
> - Drop quotes from around the string constants.
>
> Changelog v4:
> - Redistribute the properties between generic ones, USB HCD-specific and
> USB DRD-specific.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more time.
> ---
> .../devicetree/bindings/usb/generic.txt | 57 --------------
> .../devicetree/bindings/usb/usb-drd.yaml | 77 +++++++++++++++++++
> .../devicetree/bindings/usb/usb-hcd.yaml | 5 ++
> .../devicetree/bindings/usb/usb.yaml | 22 ++++++
> 4 files changed, 104 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> create mode 100644 Documentation/devicetree/bindings/usb/usb-drd.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> deleted file mode 100644
> index ba472e7aefc9..000000000000
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Generic USB Properties
> -
> -Optional properties:
> - - maximum-speed: tells USB controllers we want to work up to a certain
> - speed. Valid arguments are "super-speed-plus",
> - "super-speed", "high-speed", "full-speed" and
> - "low-speed". In case this isn't passed via DT, USB
> - controllers should default to their maximum HW
> - capability.
> - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> - particular mode. Valid arguments are "host",
> - "peripheral" and "otg". In case this attribute isn't
> - passed via DT, USB DRD controllers should default to
> - OTG.
> - - phy_type: tells USB controllers that we want to configure the core to support
> - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> - selected. Valid arguments are "utmi" and "utmi_wide".
> - In case this isn't passed via DT, USB controllers should
> - default to HW capability.
> - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> - with which the device and its descriptors are compliant,
> - in binary-coded decimal (i.e. 2.0 is 0200H). This
> - property is used if any real OTG features(HNP/SRP/ADP)
> - is enabled, if ADP is required, otg-rev should be
> - 0x0200 or above.
> - - companion: phandle of a companion
> - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally HNP
> - is the basic function of real OTG except you want it
> - to be a srp-capable only B device.
> - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> - optional for OTG device.
> - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> - optional for OTG device.
> - - usb-role-switch: boolean, indicates that the device is capable of assigning
> - the USB data role (USB host or USB device) for a given
> - USB connector, such as Type-C, Type-B(micro).
> - see connector/usb-connector.yaml.
> - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> - device default operation mode of controller while usb
> - role is USB_ROLE_NONE. Valid arguments are "host" and
> - "peripheral". Defaults to "peripheral" if not
> - specified.
> -
> -
> -This is an attribute to a USB controller such as:
> -
> -dwc3@4a030000 {
> - compatible = "synopsys,dwc3";
> - reg = <0x4a030000 0xcfff>;
> - interrupts = <0 92 4>
> - usb-phy = <&usb2_phy>, <&usb3,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git a/Documentation/devicetree/bindings/usb/usb-drd.yaml b/Documentation/devicetree/bindings/usb/usb-drd.yaml
> new file mode 100644
> index 000000000000..f3a64c46dcd0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-drd.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/usb-drd.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic USB OTG Controller Device Tree Bindings
> +
> +maintainers:
> + - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> +
> +properties:
> + otg-rev:
> + description:
> + Tells usb driver the release number of the OTG and EH supplement with
> + which the device and its descriptors are compliant, in binary-coded
> + decimal (i.e. 2.0 is 0200H). This property is used if any real OTG
> + features (HNP/SRP/ADP) is enabled. If ADP is required, otg-rev should be
> + 0x0200 or above.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + dr_mode:
> + description:
> + Tells Dual-Role USB controllers that we want to work on a particular
> + mode. In case this attribute isn't passed via DT, USB DRD controllers
> + should default to OTG.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [host, peripheral, otg]
> +
> + hnp-disable:
> + description:
> + Tells OTG controllers we want to disable OTG HNP. Normally HNP is the
> + basic function of real OTG except you want it to be a srp-capable only B
> + device.
> + type: boolean
> +
> + srp-disable:
> + description:
> + Tells OTG controllers we want to disable OTG SRP. SRP is optional for OTG
> + device.
> + type: boolean
> +
> + adp-disable:
> + description:
> + Tells OTG controllers we want to disable OTG ADP. ADP is optional for OTG
> + device.
> + type: boolean
> +
> + usb-role-switch:
> + description:
> + Indicates that the device is capable of assigning the USB data role
> + (USB host or USB device) for a given USB connector, such as Type-C,
> + Type-B(micro). See connector/usb-connector.yaml.
> +
> + role-switch-default-mode:
> + description:
> + Indicates if usb-role-switch is enabled, the device default operation
> + mode of controller while usb role is USB_ROLE_NONE.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [host, peripheral]
> + default: peripheral
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + usb@4a030000 {
> + compatible = "snps,dwc3";
> + reg = <0x4a030000 0xcfff>;
> + interrupts = <0 92 4>;
> + usb-phy = <&usb2_phy>, <&usb3_phy>;
> + maximum-speed = "super-speed";
> + dr_mode = "otg";
> + phy_type = "utmi_wide";
> + otg-rev = <0x0200>;
> + adp-disable;
> + };
> diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> index 81f3ad1419d8..52cc84c400c0 100644
> --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> @@ -12,6 +12,11 @@ maintainers:
> allOf:
> - $ref: usb.yaml#
>
> +properties:
> + companion:
> + description: Phandle of a companion device
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> additionalProperties: true
>
> examples:
> diff --git a/Documentation/devicetree/bindings/usb/usb.yaml b/Documentation/devicetree/bindings/usb/usb.yaml
> index 941ad59fbac5..991c02725e2b 100644
> --- a/Documentation/devicetree/bindings/usb/usb.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb.yaml
> @@ -24,6 +24,28 @@ properties:
> description:
> Name specifier for the USB PHY
>
> + phy_type:
> + description:
> + Tells USB controllers that we want to configure the core to support a
> + UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected. In case
> + this isn't passed via DT, USB controllers should default to HW
> + capability.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [utmi, utmi_wide]
> +
> + maximum-speed:
> + description:
indent: two blank space, like v4
> + Tells USB controllers we want to work up to a certain speed. In case this
> + isn't passed via DT, USB controllers should default to their maximum HW
> + capability.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum:
> + - low-speed
> + - full-speed
> + - high-speed
> + - super-speed
> + - super-speed-plus
> +
> additionalProperties: true
>
> ...
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update 68k Mac entry
From: Geert Uytterhoeven @ 2020-12-07 7:35 UTC (permalink / raw)
To: Finn Thain
Cc: Linux Kernel Mailing List, linux-m68k, linuxppc-dev,
Joshua Thompson
In-Reply-To: <fbac2cd8632bb719f48cd1368910abd310548a0e.1607139987.git.fthain@telegraphics.com.au>
Hi Finn,
On Sat, Dec 5, 2020 at 4:49 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> Two files under drivers/macintosh are actually m68k-only. I think that
> patches for these files should be reviewed in the appropriate forum and
> merged via the appropriate tree, rather than falling to the powerpc
> maintainers to deal with. Update the "M68K ON APPLE MACINTOSH" section
> accordingly.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Joshua Thompson <funaho@jurai.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-m68k@lists.linux-m68k.org
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
i.e. will queue in the m68k for-v5.11 branch.
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
* [powerpc:next-test 42/193] arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: sparse: incorrect type in argument 1 (different address spaces)
From: kernel test robot @ 2020-12-07 6:38 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, kbuild-all
[-- Attachment #1: Type: text/plain, Size: 6477 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: 8817aabb1bdd5811130f94ff6442bb19c9158a3a
commit: 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e [42/193] powerpc: inline iomap accessors
config: powerpc64-randconfig-s032-20201207 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-179-ga00755aa-dirty
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
"sparse warnings: (new ones prefixed by >>)"
arch/powerpc/platforms/44x/ppc476.c:236:17: sparse: sparse: cast removes address space '__iomem' of expression
>> arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got unsigned char [usertype] * @@
arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: expected void const volatile [noderef] __iomem *addr
arch/powerpc/platforms/44x/ppc476.c:241:34: sparse: got unsigned char [usertype] *
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got unsigned char [usertype] *[assigned] fpga @@
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: expected void volatile [noderef] __iomem *addr
arch/powerpc/platforms/44x/ppc476.c:243:17: sparse: got unsigned char [usertype] *[assigned] fpga
vim +241 arch/powerpc/platforms/44x/ppc476.c
228d55053397e6d arch/powerpc/platforms/44x/currituck.c Tony Breeds 2011-11-30 217
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 218 static int board_rev = -1;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 219 static int __init ppc47x_get_board_rev(void)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 220 {
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 221 int reg;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 222 u8 *fpga;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 223 struct device_node *np = NULL;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 224
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 225 if (of_machine_is_compatible("ibm,currituck")) {
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 226 np = of_find_compatible_node(NULL, NULL, "ibm,currituck-fpga");
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 227 reg = 0;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 228 } else if (of_machine_is_compatible("ibm,akebono")) {
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 229 np = of_find_compatible_node(NULL, NULL, "ibm,akebono-fpga");
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 230 reg = 2;
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 231 }
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 232
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 233 if (!np)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 234 goto fail;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 235
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 @236 fpga = (u8 *) of_iomap(np, 0);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 237 of_node_put(np);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 238 if (!fpga)
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 239 goto fail;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 240
2a2c74b2efcb1a0 arch/powerpc/platforms/44x/ppc476.c Alistair Popple 2014-03-06 @241 board_rev = ioread8(fpga + reg) & 0x03;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 242 pr_info("%s: Found board revision %d\n", __func__, board_rev);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 243 iounmap(fpga);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 244 return 0;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 245
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 246 fail:
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 247 pr_info("%s: Unable to find board revision\n", __func__);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 248 return 0;
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 249 }
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 250 machine_arch_initcall(ppc47x, ppc47x_get_board_rev);
ab9a4183fddf232 arch/powerpc/platforms/44x/currituck.c Alistair Popple 2013-05-09 251
:::::: The code at line 241 was first introduced by commit
:::::: 2a2c74b2efcb1a0ca3fdcb5fbb96ad8de6a29177 IBM Akebono: Add the Akebono platform
:::::: TO: Alistair Popple <alistair@popple.id.au>
:::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
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: 32853 bytes --]
^ permalink raw reply
* [PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver
From: Michael Ellerman @ 2020-12-07 4:02 UTC (permalink / raw)
To: bp
Cc: tony.luck, rric, linux-kernel, linuxppc-dev, james.morse, mchehab,
linux-edac
The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is
not user-selectable, and the last code that selected it was removed
with the C2K board support in 2018, see:
92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
That means the driver is now dead code, so remove it.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
drivers/edac/Kconfig | 7 -
drivers/edac/Makefile | 1 -
drivers/edac/mv64x60_edac.c | 883 ------------------------------------
drivers/edac/mv64x60_edac.h | 114 -----
4 files changed, 1005 deletions(-)
delete mode 100644 drivers/edac/mv64x60_edac.c
delete mode 100644 drivers/edac/mv64x60_edac.h
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index fa0c3b5797e4..f3816f1131ed 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -292,13 +292,6 @@ config EDAC_LAYERSCAPE
Support for error detection and correction on Freescale memory
controllers on Layerscape SoCs.
-config EDAC_MV64X60
- tristate "Marvell MV64x60"
- depends on MV64X60
- help
- Support for error detection and correction on the Marvell
- MV64360 and MV64460 chipsets.
-
config EDAC_PASEMI
tristate "PA Semi PWRficient"
depends on PPC_PASEMI && PCI
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 3cd1aeb0a916..464d3d8d850a 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -65,7 +65,6 @@ obj-$(CONFIG_EDAC_SKX) += skx_edac.o
i10nm_edac-y := skx_common.o i10nm_base.o
obj-$(CONFIG_EDAC_I10NM) += i10nm_edac.o
-obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
obj-$(CONFIG_EDAC_CELL) += cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
obj-$(CONFIG_EDAC_AMD8111) += amd8111_edac.o
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
deleted file mode 100644
index 3c68bb525d5d..000000000000
--- a/drivers/edac/mv64x60_edac.c
+++ /dev/null
@@ -1,883 +0,0 @@
-/*
- * Marvell MV64x60 Memory Controller kernel module for PPC platforms
- *
- * Author: Dave Jiang <djiang@mvista.com>
- *
- * 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/io.h>
-#include <linux/edac.h>
-#include <linux/gfp.h>
-
-#include "edac_module.h"
-#include "mv64x60_edac.h"
-
-static const char *mv64x60_ctl_name = "MV64x60";
-static int edac_dev_idx;
-static int edac_pci_idx;
-static int edac_mc_idx;
-
-/*********************** PCI err device **********************************/
-#ifdef CONFIG_PCI
-static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
-{
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 cause;
-
- cause = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!cause)
- return;
-
- printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
- printk(KERN_ERR "Cause register: 0x%08x\n", cause);
- printk(KERN_ERR "Address Low: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
- printk(KERN_ERR "Address High: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
- printk(KERN_ERR "Attribute: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
- printk(KERN_ERR "Command: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
- writel(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
-
- if (cause & MV64X60_PCI_PE_MASK)
- edac_pci_handle_pe(pci, pci->ctl_name);
-
- if (!(cause & MV64X60_PCI_PE_MASK))
- edac_pci_handle_npe(pci, pci->ctl_name);
-}
-
-static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
-{
- struct edac_pci_ctl_info *pci = dev_id;
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 val;
-
- val = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!val)
- return IRQ_NONE;
-
- mv64x60_pci_check(pci);
-
- return IRQ_HANDLED;
-}
-
-/*
- * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
- * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
- * well. IOW, don't set bit 0.
- */
-
-/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
-static int __init mv64x60_pci_fixup(struct platform_device *pdev)
-{
- struct resource *r;
- void __iomem *pci_serr;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "PCI err regs\n", __func__);
- return -ENOENT;
- }
-
- pci_serr = ioremap(r->start, resource_size(r));
- if (!pci_serr)
- return -ENOMEM;
-
- writel(readl(pci_serr) & ~0x1, pci_serr);
- iounmap(pci_serr);
-
- return 0;
-}
-
-static int mv64x60_pci_err_probe(struct platform_device *pdev)
-{
- struct edac_pci_ctl_info *pci;
- struct mv64x60_pci_pdata *pdata;
- struct resource *r;
- int res = 0;
-
- if (!devres_open_group(&pdev->dev, mv64x60_pci_err_probe, GFP_KERNEL))
- return -ENOMEM;
-
- pci = edac_pci_alloc_ctl_info(sizeof(*pdata), "mv64x60_pci_err");
- if (!pci)
- return -ENOMEM;
-
- pdata = pci->pvt_info;
-
- pdata->pci_hose = pdev->id;
- pdata->name = "mv64x60_pci_err";
- platform_set_drvdata(pdev, pci);
- pci->dev = &pdev->dev;
- pci->dev_name = dev_name(&pdev->dev);
- pci->mod_name = EDAC_MOD_STR;
- pci->ctl_name = pdata->name;
-
- if (edac_op_state == EDAC_OPSTATE_POLL)
- pci->edac_check = mv64x60_pci_check;
-
- pdata->edac_idx = edac_pci_idx++;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "PCI err regs\n", __func__);
- res = -ENOENT;
- goto err;
- }
-
- if (!devm_request_mem_region(&pdev->dev,
- r->start,
- resource_size(r),
- pdata->name)) {
- printk(KERN_ERR "%s: Error while requesting mem region\n",
- __func__);
- res = -EBUSY;
- goto err;
- }
-
- pdata->pci_vbase = devm_ioremap(&pdev->dev,
- r->start,
- resource_size(r));
- if (!pdata->pci_vbase) {
- printk(KERN_ERR "%s: Unable to setup PCI err regs\n", __func__);
- res = -ENOMEM;
- goto err;
- }
-
- res = mv64x60_pci_fixup(pdev);
- if (res < 0) {
- printk(KERN_ERR "%s: PCI fixup failed\n", __func__);
- goto err;
- }
-
- writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
- writel(MV64X60_PCIx_ERR_MASK_VAL,
- pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
-
- if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
- edac_dbg(3, "failed edac_pci_add_device()\n");
- goto err;
- }
-
- if (edac_op_state == EDAC_OPSTATE_INT) {
- pdata->irq = platform_get_irq(pdev, 0);
- res = devm_request_irq(&pdev->dev,
- pdata->irq,
- mv64x60_pci_isr,
- 0,
- "[EDAC] PCI err",
- pci);
- if (res < 0) {
- printk(KERN_ERR "%s: Unable to request irq %d for "
- "MV64x60 PCI ERR\n", __func__, pdata->irq);
- res = -ENODEV;
- goto err2;
- }
- printk(KERN_INFO EDAC_MOD_STR " acquired irq %d for PCI Err\n",
- pdata->irq);
- }
-
- devres_remove_group(&pdev->dev, mv64x60_pci_err_probe);
-
- /* get this far and it's successful */
- edac_dbg(3, "success\n");
-
- return 0;
-
-err2:
- edac_pci_del_device(&pdev->dev);
-err:
- edac_pci_free_ctl_info(pci);
- devres_release_group(&pdev->dev, mv64x60_pci_err_probe);
- return res;
-}
-
-static int mv64x60_pci_err_remove(struct platform_device *pdev)
-{
- struct edac_pci_ctl_info *pci = platform_get_drvdata(pdev);
-
- edac_dbg(0, "\n");
-
- edac_pci_del_device(&pdev->dev);
-
- edac_pci_free_ctl_info(pci);
-
- return 0;
-}
-
-static struct platform_driver mv64x60_pci_err_driver = {
- .probe = mv64x60_pci_err_probe,
- .remove = mv64x60_pci_err_remove,
- .driver = {
- .name = "mv64x60_pci_err",
- }
-};
-
-#endif /* CONFIG_PCI */
-
-/*********************** SRAM err device **********************************/
-static void mv64x60_sram_check(struct edac_device_ctl_info *edac_dev)
-{
- struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
- u32 cause;
-
- cause = readl(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
- if (!cause)
- return;
-
- printk(KERN_ERR "Error in internal SRAM\n");
- printk(KERN_ERR "Cause register: 0x%08x\n", cause);
- printk(KERN_ERR "Address Low: 0x%08x\n",
- readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
- printk(KERN_ERR "Address High: 0x%08x\n",
- readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
- printk(KERN_ERR "Data Low: 0x%08x\n",
- readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
- printk(KERN_ERR "Data High: 0x%08x\n",
- readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
- printk(KERN_ERR "Parity: 0x%08x\n",
- readl(pdata->sram_vbase + MV64X60_SRAM_ERR_PARITY));
- writel(0, pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
-
- edac_device_handle_ue(edac_dev, 0, 0, edac_dev->ctl_name);
-}
-
-static irqreturn_t mv64x60_sram_isr(int irq, void *dev_id)
-{
- struct edac_device_ctl_info *edac_dev = dev_id;
- struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
- u32 cause;
-
- cause = readl(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
- if (!cause)
- return IRQ_NONE;
-
- mv64x60_sram_check(edac_dev);
-
- return IRQ_HANDLED;
-}
-
-static int mv64x60_sram_err_probe(struct platform_device *pdev)
-{
- struct edac_device_ctl_info *edac_dev;
- struct mv64x60_sram_pdata *pdata;
- struct resource *r;
- int res = 0;
-
- if (!devres_open_group(&pdev->dev, mv64x60_sram_err_probe, GFP_KERNEL))
- return -ENOMEM;
-
- edac_dev = edac_device_alloc_ctl_info(sizeof(*pdata),
- "sram", 1, NULL, 0, 0, NULL, 0,
- edac_dev_idx);
- if (!edac_dev) {
- devres_release_group(&pdev->dev, mv64x60_sram_err_probe);
- return -ENOMEM;
- }
-
- pdata = edac_dev->pvt_info;
- pdata->name = "mv64x60_sram_err";
- edac_dev->dev = &pdev->dev;
- platform_set_drvdata(pdev, edac_dev);
- edac_dev->dev_name = dev_name(&pdev->dev);
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "SRAM err regs\n", __func__);
- res = -ENOENT;
- goto err;
- }
-
- if (!devm_request_mem_region(&pdev->dev,
- r->start,
- resource_size(r),
- pdata->name)) {
- printk(KERN_ERR "%s: Error while request mem region\n",
- __func__);
- res = -EBUSY;
- goto err;
- }
-
- pdata->sram_vbase = devm_ioremap(&pdev->dev,
- r->start,
- resource_size(r));
- if (!pdata->sram_vbase) {
- printk(KERN_ERR "%s: Unable to setup SRAM err regs\n",
- __func__);
- res = -ENOMEM;
- goto err;
- }
-
- /* setup SRAM err registers */
- writel(0, pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
-
- edac_dev->mod_name = EDAC_MOD_STR;
- edac_dev->ctl_name = pdata->name;
-
- if (edac_op_state == EDAC_OPSTATE_POLL)
- edac_dev->edac_check = mv64x60_sram_check;
-
- pdata->edac_idx = edac_dev_idx++;
-
- if (edac_device_add_device(edac_dev) > 0) {
- edac_dbg(3, "failed edac_device_add_device()\n");
- goto err;
- }
-
- if (edac_op_state == EDAC_OPSTATE_INT) {
- pdata->irq = platform_get_irq(pdev, 0);
- res = devm_request_irq(&pdev->dev,
- pdata->irq,
- mv64x60_sram_isr,
- 0,
- "[EDAC] SRAM err",
- edac_dev);
- if (res < 0) {
- printk(KERN_ERR
- "%s: Unable to request irq %d for "
- "MV64x60 SRAM ERR\n", __func__, pdata->irq);
- res = -ENODEV;
- goto err2;
- }
-
- printk(KERN_INFO EDAC_MOD_STR " acquired irq %d for SRAM Err\n",
- pdata->irq);
- }
-
- devres_remove_group(&pdev->dev, mv64x60_sram_err_probe);
-
- /* get this far and it's successful */
- edac_dbg(3, "success\n");
-
- return 0;
-
-err2:
- edac_device_del_device(&pdev->dev);
-err:
- devres_release_group(&pdev->dev, mv64x60_sram_err_probe);
- edac_device_free_ctl_info(edac_dev);
- return res;
-}
-
-static int mv64x60_sram_err_remove(struct platform_device *pdev)
-{
- struct edac_device_ctl_info *edac_dev = platform_get_drvdata(pdev);
-
- edac_dbg(0, "\n");
-
- edac_device_del_device(&pdev->dev);
- edac_device_free_ctl_info(edac_dev);
-
- return 0;
-}
-
-static struct platform_driver mv64x60_sram_err_driver = {
- .probe = mv64x60_sram_err_probe,
- .remove = mv64x60_sram_err_remove,
- .driver = {
- .name = "mv64x60_sram_err",
- }
-};
-
-/*********************** CPU err device **********************************/
-static void mv64x60_cpu_check(struct edac_device_ctl_info *edac_dev)
-{
- struct mv64x60_cpu_pdata *pdata = edac_dev->pvt_info;
- u32 cause;
-
- cause = readl(pdata->cpu_vbase[1] + MV64x60_CPU_ERR_CAUSE) &
- MV64x60_CPU_CAUSE_MASK;
- if (!cause)
- return;
-
- printk(KERN_ERR "Error on CPU interface\n");
- printk(KERN_ERR "Cause register: 0x%08x\n", cause);
- printk(KERN_ERR "Address Low: 0x%08x\n",
- readl(pdata->cpu_vbase[0] + MV64x60_CPU_ERR_ADDR_LO));
- printk(KERN_ERR "Address High: 0x%08x\n",
- readl(pdata->cpu_vbase[0] + MV64x60_CPU_ERR_ADDR_HI));
- printk(KERN_ERR "Data Low: 0x%08x\n",
- readl(pdata->cpu_vbase[1] + MV64x60_CPU_ERR_DATA_LO));
- printk(KERN_ERR "Data High: 0x%08x\n",
- readl(pdata->cpu_vbase[1] + MV64x60_CPU_ERR_DATA_HI));
- printk(KERN_ERR "Parity: 0x%08x\n",
- readl(pdata->cpu_vbase[1] + MV64x60_CPU_ERR_PARITY));
- writel(0, pdata->cpu_vbase[1] + MV64x60_CPU_ERR_CAUSE);
-
- edac_device_handle_ue(edac_dev, 0, 0, edac_dev->ctl_name);
-}
-
-static irqreturn_t mv64x60_cpu_isr(int irq, void *dev_id)
-{
- struct edac_device_ctl_info *edac_dev = dev_id;
- struct mv64x60_cpu_pdata *pdata = edac_dev->pvt_info;
- u32 cause;
-
- cause = readl(pdata->cpu_vbase[1] + MV64x60_CPU_ERR_CAUSE) &
- MV64x60_CPU_CAUSE_MASK;
- if (!cause)
- return IRQ_NONE;
-
- mv64x60_cpu_check(edac_dev);
-
- return IRQ_HANDLED;
-}
-
-static int mv64x60_cpu_err_probe(struct platform_device *pdev)
-{
- struct edac_device_ctl_info *edac_dev;
- struct resource *r;
- struct mv64x60_cpu_pdata *pdata;
- int res = 0;
-
- if (!devres_open_group(&pdev->dev, mv64x60_cpu_err_probe, GFP_KERNEL))
- return -ENOMEM;
-
- edac_dev = edac_device_alloc_ctl_info(sizeof(*pdata),
- "cpu", 1, NULL, 0, 0, NULL, 0,
- edac_dev_idx);
- if (!edac_dev) {
- devres_release_group(&pdev->dev, mv64x60_cpu_err_probe);
- return -ENOMEM;
- }
-
- pdata = edac_dev->pvt_info;
- pdata->name = "mv64x60_cpu_err";
- edac_dev->dev = &pdev->dev;
- platform_set_drvdata(pdev, edac_dev);
- edac_dev->dev_name = dev_name(&pdev->dev);
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "CPU err regs\n", __func__);
- res = -ENOENT;
- goto err;
- }
-
- if (!devm_request_mem_region(&pdev->dev,
- r->start,
- resource_size(r),
- pdata->name)) {
- printk(KERN_ERR "%s: Error while requesting mem region\n",
- __func__);
- res = -EBUSY;
- goto err;
- }
-
- pdata->cpu_vbase[0] = devm_ioremap(&pdev->dev,
- r->start,
- resource_size(r));
- if (!pdata->cpu_vbase[0]) {
- printk(KERN_ERR "%s: Unable to setup CPU err regs\n", __func__);
- res = -ENOMEM;
- goto err;
- }
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "CPU err regs\n", __func__);
- res = -ENOENT;
- goto err;
- }
-
- if (!devm_request_mem_region(&pdev->dev,
- r->start,
- resource_size(r),
- pdata->name)) {
- printk(KERN_ERR "%s: Error while requesting mem region\n",
- __func__);
- res = -EBUSY;
- goto err;
- }
-
- pdata->cpu_vbase[1] = devm_ioremap(&pdev->dev,
- r->start,
- resource_size(r));
- if (!pdata->cpu_vbase[1]) {
- printk(KERN_ERR "%s: Unable to setup CPU err regs\n", __func__);
- res = -ENOMEM;
- goto err;
- }
-
- /* setup CPU err registers */
- writel(0, pdata->cpu_vbase[1] + MV64x60_CPU_ERR_CAUSE);
- writel(0, pdata->cpu_vbase[1] + MV64x60_CPU_ERR_MASK);
- writel(0x000000ff, pdata->cpu_vbase[1] + MV64x60_CPU_ERR_MASK);
-
- edac_dev->mod_name = EDAC_MOD_STR;
- edac_dev->ctl_name = pdata->name;
- if (edac_op_state == EDAC_OPSTATE_POLL)
- edac_dev->edac_check = mv64x60_cpu_check;
-
- pdata->edac_idx = edac_dev_idx++;
-
- if (edac_device_add_device(edac_dev) > 0) {
- edac_dbg(3, "failed edac_device_add_device()\n");
- goto err;
- }
-
- if (edac_op_state == EDAC_OPSTATE_INT) {
- pdata->irq = platform_get_irq(pdev, 0);
- res = devm_request_irq(&pdev->dev,
- pdata->irq,
- mv64x60_cpu_isr,
- 0,
- "[EDAC] CPU err",
- edac_dev);
- if (res < 0) {
- printk(KERN_ERR
- "%s: Unable to request irq %d for MV64x60 "
- "CPU ERR\n", __func__, pdata->irq);
- res = -ENODEV;
- goto err2;
- }
-
- printk(KERN_INFO EDAC_MOD_STR
- " acquired irq %d for CPU Err\n", pdata->irq);
- }
-
- devres_remove_group(&pdev->dev, mv64x60_cpu_err_probe);
-
- /* get this far and it's successful */
- edac_dbg(3, "success\n");
-
- return 0;
-
-err2:
- edac_device_del_device(&pdev->dev);
-err:
- devres_release_group(&pdev->dev, mv64x60_cpu_err_probe);
- edac_device_free_ctl_info(edac_dev);
- return res;
-}
-
-static int mv64x60_cpu_err_remove(struct platform_device *pdev)
-{
- struct edac_device_ctl_info *edac_dev = platform_get_drvdata(pdev);
-
- edac_dbg(0, "\n");
-
- edac_device_del_device(&pdev->dev);
- edac_device_free_ctl_info(edac_dev);
- return 0;
-}
-
-static struct platform_driver mv64x60_cpu_err_driver = {
- .probe = mv64x60_cpu_err_probe,
- .remove = mv64x60_cpu_err_remove,
- .driver = {
- .name = "mv64x60_cpu_err",
- }
-};
-
-/*********************** DRAM err device **********************************/
-
-static void mv64x60_mc_check(struct mem_ctl_info *mci)
-{
- struct mv64x60_mc_pdata *pdata = mci->pvt_info;
- u32 reg;
- u32 err_addr;
- u32 sdram_ecc;
- u32 comp_ecc;
- u32 syndrome;
-
- reg = readl(pdata->mc_vbase + MV64X60_SDRAM_ERR_ADDR);
- if (!reg)
- return;
-
- err_addr = reg & ~0x3;
- sdram_ecc = readl(pdata->mc_vbase + MV64X60_SDRAM_ERR_ECC_RCVD);
- comp_ecc = readl(pdata->mc_vbase + MV64X60_SDRAM_ERR_ECC_CALC);
- syndrome = sdram_ecc ^ comp_ecc;
-
- /* first bit clear in ECC Err Reg, 1 bit error, correctable by HW */
- if (!(reg & 0x1))
- edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci, 1,
- err_addr >> PAGE_SHIFT,
- err_addr & PAGE_MASK, syndrome,
- 0, 0, -1,
- mci->ctl_name, "");
- else /* 2 bit error, UE */
- edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci, 1,
- err_addr >> PAGE_SHIFT,
- err_addr & PAGE_MASK, 0,
- 0, 0, -1,
- mci->ctl_name, "");
-
- /* clear the error */
- writel(0, pdata->mc_vbase + MV64X60_SDRAM_ERR_ADDR);
-}
-
-static irqreturn_t mv64x60_mc_isr(int irq, void *dev_id)
-{
- struct mem_ctl_info *mci = dev_id;
- struct mv64x60_mc_pdata *pdata = mci->pvt_info;
- u32 reg;
-
- reg = readl(pdata->mc_vbase + MV64X60_SDRAM_ERR_ADDR);
- if (!reg)
- return IRQ_NONE;
-
- /* writing 0's to the ECC err addr in check function clears irq */
- mv64x60_mc_check(mci);
-
- return IRQ_HANDLED;
-}
-
-static void get_total_mem(struct mv64x60_mc_pdata *pdata)
-{
- struct device_node *np = NULL;
- const unsigned int *reg;
-
- np = of_find_node_by_type(NULL, "memory");
- if (!np)
- return;
-
- reg = of_get_property(np, "reg", NULL);
-
- pdata->total_mem = reg[1];
-}
-
-static void mv64x60_init_csrows(struct mem_ctl_info *mci,
- struct mv64x60_mc_pdata *pdata)
-{
- struct csrow_info *csrow;
- struct dimm_info *dimm;
-
- u32 devtype;
- u32 ctl;
-
- get_total_mem(pdata);
-
- ctl = readl(pdata->mc_vbase + MV64X60_SDRAM_CONFIG);
-
- csrow = mci->csrows[0];
- dimm = csrow->channels[0]->dimm;
-
- dimm->nr_pages = pdata->total_mem >> PAGE_SHIFT;
- dimm->grain = 8;
-
- dimm->mtype = (ctl & MV64X60_SDRAM_REGISTERED) ? MEM_RDDR : MEM_DDR;
-
- devtype = (ctl >> 20) & 0x3;
- switch (devtype) {
- case 0x0:
- dimm->dtype = DEV_X32;
- break;
- case 0x2: /* could be X8 too, but no way to tell */
- dimm->dtype = DEV_X16;
- break;
- case 0x3:
- dimm->dtype = DEV_X4;
- break;
- default:
- dimm->dtype = DEV_UNKNOWN;
- break;
- }
-
- dimm->edac_mode = EDAC_SECDED;
-}
-
-static int mv64x60_mc_err_probe(struct platform_device *pdev)
-{
- struct mem_ctl_info *mci;
- struct edac_mc_layer layers[2];
- struct mv64x60_mc_pdata *pdata;
- struct resource *r;
- u32 ctl;
- int res = 0;
-
- if (!devres_open_group(&pdev->dev, mv64x60_mc_err_probe, GFP_KERNEL))
- return -ENOMEM;
-
- layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
- layers[0].size = 1;
- layers[0].is_virt_csrow = true;
- layers[1].type = EDAC_MC_LAYER_CHANNEL;
- layers[1].size = 1;
- layers[1].is_virt_csrow = false;
- mci = edac_mc_alloc(edac_mc_idx, ARRAY_SIZE(layers), layers,
- sizeof(struct mv64x60_mc_pdata));
- if (!mci) {
- printk(KERN_ERR "%s: No memory for CPU err\n", __func__);
- devres_release_group(&pdev->dev, mv64x60_mc_err_probe);
- return -ENOMEM;
- }
-
- pdata = mci->pvt_info;
- mci->pdev = &pdev->dev;
- platform_set_drvdata(pdev, mci);
- pdata->name = "mv64x60_mc_err";
- mci->dev_name = dev_name(&pdev->dev);
- pdata->edac_idx = edac_mc_idx++;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- printk(KERN_ERR "%s: Unable to get resource for "
- "MC err regs\n", __func__);
- res = -ENOENT;
- goto err;
- }
-
- if (!devm_request_mem_region(&pdev->dev,
- r->start,
- resource_size(r),
- pdata->name)) {
- printk(KERN_ERR "%s: Error while requesting mem region\n",
- __func__);
- res = -EBUSY;
- goto err;
- }
-
- pdata->mc_vbase = devm_ioremap(&pdev->dev,
- r->start,
- resource_size(r));
- if (!pdata->mc_vbase) {
- printk(KERN_ERR "%s: Unable to setup MC err regs\n", __func__);
- res = -ENOMEM;
- goto err;
- }
-
- ctl = readl(pdata->mc_vbase + MV64X60_SDRAM_CONFIG);
- if (!(ctl & MV64X60_SDRAM_ECC)) {
- /* Non-ECC RAM? */
- printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__);
- res = -ENODEV;
- goto err;
- }
-
- edac_dbg(3, "init mci\n");
- mci->mtype_cap = MEM_FLAG_RDDR | MEM_FLAG_DDR;
- mci->edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_SECDED;
- mci->edac_cap = EDAC_FLAG_SECDED;
- mci->mod_name = EDAC_MOD_STR;
- mci->ctl_name = mv64x60_ctl_name;
-
- if (edac_op_state == EDAC_OPSTATE_POLL)
- mci->edac_check = mv64x60_mc_check;
-
- mci->ctl_page_to_phys = NULL;
-
- mci->scrub_mode = SCRUB_SW_SRC;
-
- mv64x60_init_csrows(mci, pdata);
-
- /* setup MC registers */
- writel(0, pdata->mc_vbase + MV64X60_SDRAM_ERR_ADDR);
- ctl = readl(pdata->mc_vbase + MV64X60_SDRAM_ERR_ECC_CNTL);
- ctl = (ctl & 0xff00ffff) | 0x10000;
- writel(ctl, pdata->mc_vbase + MV64X60_SDRAM_ERR_ECC_CNTL);
-
- res = edac_mc_add_mc(mci);
- if (res) {
- edac_dbg(3, "failed edac_mc_add_mc()\n");
- goto err;
- }
-
- if (edac_op_state == EDAC_OPSTATE_INT) {
- /* acquire interrupt that reports errors */
- pdata->irq = platform_get_irq(pdev, 0);
- res = devm_request_irq(&pdev->dev,
- pdata->irq,
- mv64x60_mc_isr,
- 0,
- "[EDAC] MC err",
- mci);
- if (res < 0) {
- printk(KERN_ERR "%s: Unable to request irq %d for "
- "MV64x60 DRAM ERR\n", __func__, pdata->irq);
- res = -ENODEV;
- goto err2;
- }
-
- printk(KERN_INFO EDAC_MOD_STR " acquired irq %d for MC Err\n",
- pdata->irq);
- }
-
- /* get this far and it's successful */
- edac_dbg(3, "success\n");
-
- return 0;
-
-err2:
- edac_mc_del_mc(&pdev->dev);
-err:
- devres_release_group(&pdev->dev, mv64x60_mc_err_probe);
- edac_mc_free(mci);
- return res;
-}
-
-static int mv64x60_mc_err_remove(struct platform_device *pdev)
-{
- struct mem_ctl_info *mci = platform_get_drvdata(pdev);
-
- edac_dbg(0, "\n");
-
- edac_mc_del_mc(&pdev->dev);
- edac_mc_free(mci);
- return 0;
-}
-
-static struct platform_driver mv64x60_mc_err_driver = {
- .probe = mv64x60_mc_err_probe,
- .remove = mv64x60_mc_err_remove,
- .driver = {
- .name = "mv64x60_mc_err",
- }
-};
-
-static struct platform_driver * const drivers[] = {
- &mv64x60_mc_err_driver,
- &mv64x60_cpu_err_driver,
- &mv64x60_sram_err_driver,
-#ifdef CONFIG_PCI
- &mv64x60_pci_err_driver,
-#endif
-};
-
-static int __init mv64x60_edac_init(void)
-{
-
- printk(KERN_INFO "Marvell MV64x60 EDAC driver " MV64x60_REVISION "\n");
- printk(KERN_INFO "\t(C) 2006-2007 MontaVista Software\n");
-
- /* make sure error reporting method is sane */
- switch (edac_op_state) {
- case EDAC_OPSTATE_POLL:
- case EDAC_OPSTATE_INT:
- break;
- default:
- edac_op_state = EDAC_OPSTATE_INT;
- break;
- }
-
- return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
-}
-module_init(mv64x60_edac_init);
-
-static void __exit mv64x60_edac_exit(void)
-{
- platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
-}
-module_exit(mv64x60_edac_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Montavista Software, Inc.");
-module_param(edac_op_state, int, 0444);
-MODULE_PARM_DESC(edac_op_state,
- "EDAC Error Reporting state: 0=Poll, 2=Interrupt");
diff --git a/drivers/edac/mv64x60_edac.h b/drivers/edac/mv64x60_edac.h
deleted file mode 100644
index c7f209c92a1a..000000000000
--- a/drivers/edac/mv64x60_edac.h
+++ /dev/null
@@ -1,114 +0,0 @@
-/*
- * EDAC defs for Marvell MV64x60 bridge chip
- *
- * Author: Dave Jiang <djiang@mvista.com>
- *
- * 2007 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- */
-#ifndef _MV64X60_EDAC_H_
-#define _MV64X60_EDAC_H_
-
-#define MV64x60_REVISION " Ver: 2.0.0"
-#define EDAC_MOD_STR "MV64x60_edac"
-
-#define mv64x60_printk(level, fmt, arg...) \
- edac_printk(level, "MV64x60", fmt, ##arg)
-
-#define mv64x60_mc_printk(mci, level, fmt, arg...) \
- edac_mc_chipset_printk(mci, level, "MV64x60", fmt, ##arg)
-
-/* CPU Error Report Registers */
-#define MV64x60_CPU_ERR_ADDR_LO 0x00 /* 0x0070 */
-#define MV64x60_CPU_ERR_ADDR_HI 0x08 /* 0x0078 */
-#define MV64x60_CPU_ERR_DATA_LO 0x00 /* 0x0128 */
-#define MV64x60_CPU_ERR_DATA_HI 0x08 /* 0x0130 */
-#define MV64x60_CPU_ERR_PARITY 0x10 /* 0x0138 */
-#define MV64x60_CPU_ERR_CAUSE 0x18 /* 0x0140 */
-#define MV64x60_CPU_ERR_MASK 0x20 /* 0x0148 */
-
-#define MV64x60_CPU_CAUSE_MASK 0x07ffffff
-
-/* SRAM Error Report Registers */
-#define MV64X60_SRAM_ERR_CAUSE 0x08 /* 0x0388 */
-#define MV64X60_SRAM_ERR_ADDR_LO 0x10 /* 0x0390 */
-#define MV64X60_SRAM_ERR_ADDR_HI 0x78 /* 0x03f8 */
-#define MV64X60_SRAM_ERR_DATA_LO 0x18 /* 0x0398 */
-#define MV64X60_SRAM_ERR_DATA_HI 0x20 /* 0x03a0 */
-#define MV64X60_SRAM_ERR_PARITY 0x28 /* 0x03a8 */
-
-/* SDRAM Controller Registers */
-#define MV64X60_SDRAM_CONFIG 0x00 /* 0x1400 */
-#define MV64X60_SDRAM_ERR_DATA_HI 0x40 /* 0x1440 */
-#define MV64X60_SDRAM_ERR_DATA_LO 0x44 /* 0x1444 */
-#define MV64X60_SDRAM_ERR_ECC_RCVD 0x48 /* 0x1448 */
-#define MV64X60_SDRAM_ERR_ECC_CALC 0x4c /* 0x144c */
-#define MV64X60_SDRAM_ERR_ADDR 0x50 /* 0x1450 */
-#define MV64X60_SDRAM_ERR_ECC_CNTL 0x54 /* 0x1454 */
-#define MV64X60_SDRAM_ERR_ECC_ERR_CNT 0x58 /* 0x1458 */
-
-#define MV64X60_SDRAM_REGISTERED 0x20000
-#define MV64X60_SDRAM_ECC 0x40000
-
-#ifdef CONFIG_PCI
-/*
- * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
- * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
- * well. IOW, don't set bit 0.
- */
-#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
-
-/* Register offsets from PCIx error address low register */
-#define MV64X60_PCI_ERROR_ADDR_LO 0x00
-#define MV64X60_PCI_ERROR_ADDR_HI 0x04
-#define MV64X60_PCI_ERROR_ATTR 0x08
-#define MV64X60_PCI_ERROR_CMD 0x10
-#define MV64X60_PCI_ERROR_CAUSE 0x18
-#define MV64X60_PCI_ERROR_MASK 0x1c
-
-#define MV64X60_PCI_ERR_SWrPerr 0x0002
-#define MV64X60_PCI_ERR_SRdPerr 0x0004
-#define MV64X60_PCI_ERR_MWrPerr 0x0020
-#define MV64X60_PCI_ERR_MRdPerr 0x0040
-
-#define MV64X60_PCI_PE_MASK (MV64X60_PCI_ERR_SWrPerr | \
- MV64X60_PCI_ERR_SRdPerr | \
- MV64X60_PCI_ERR_MWrPerr | \
- MV64X60_PCI_ERR_MRdPerr)
-
-struct mv64x60_pci_pdata {
- int pci_hose;
- void __iomem *pci_vbase;
- char *name;
- int irq;
- int edac_idx;
-};
-
-#endif /* CONFIG_PCI */
-
-struct mv64x60_mc_pdata {
- void __iomem *mc_vbase;
- int total_mem;
- char *name;
- int irq;
- int edac_idx;
-};
-
-struct mv64x60_cpu_pdata {
- void __iomem *cpu_vbase[2];
- char *name;
- int irq;
- int edac_idx;
-};
-
-struct mv64x60_sram_pdata {
- void __iomem *sram_vbase;
- char *name;
- int irq;
- int edac_idx;
-};
-
-#endif
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v6 1/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Florian Fainelli @ 2020-12-07 3:25 UTC (permalink / raw)
To: Krzysztof Wilczyński, Bjorn Helgaas, Jim Quinlan
Cc: Heiko Stuebner, Shawn Lin, Paul Mackerras, Thomas Petazzoni,
Jonathan Chocron, Toan Le, Will Deacon, Rob Herring,
Lorenzo Pieralisi, Michal Simek, linux-rockchip,
bcm-kernel-feedback-list, Jonathan Derrick, linux-pci, Ray Jui,
linux-rpi-kernel, Jonathan Cameron, linux-arm-kernel,
Scott Branden, Zhou Wang, Robert Richter, linuxppc-dev,
Nicolas Saenz Julienne
In-Reply-To: <X808JJGeIREwqIjb@rocinante>
+JimQ,
On 12/6/2020 12:16 PM, Krzysztof Wilczyński wrote:
> Hello Nicolas, Florian and Florian,
>
> [...]
>> -/* Configuration space read/write support */
>> -static inline int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
>> -{
>> - return ((PCI_SLOT(devfn) & 0x1f) << PCIE_EXT_SLOT_SHIFT)
>> - | ((PCI_FUNC(devfn) & 0x07) << PCIE_EXT_FUNC_SHIFT)
>> - | (busnr << PCIE_EXT_BUSNUM_SHIFT)
>> - | (reg & ~3);
>> -}
>> -
>> static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
>> int where)
>> {
>> @@ -716,7 +704,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
>> return PCI_SLOT(devfn) ? NULL : base + where;
>>
>> /* For devices, write to the config space index register */
>> - idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
>> + idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0);
>> writel(idx, pcie->base + PCIE_EXT_CFG_INDEX);
>> return base + PCIE_EXT_CFG_DATA + where;
>> }
> [...]
>
> Passing the hard-coded 0 as the "reg" argument here never actually did
> anything, thus the 32 bit alignment was never correctly enforced.
>
> My question would be: should this be 32 bit aligned? It seems like the
> intention was to perhaps make the alignment? I am sadly not intimately
> familiar with his hardware, so I am not sure if there is something to
> fix here or not.
>
> Also, I wonder whether it would be safe to pass the offset (the "where"
> variable) rather than hard-coded 0?
>
> Thank you for help in advance!
>
> Bjorn also asked the same question:
> https://lore.kernel.org/linux-pci/20201120203428.GA272511@bjorn-Precision-5520/
>
> Krzysztof
>
--
Florian
^ permalink raw reply
* [PATCH 2/2] powerpc/powernv/idle: Restore CIABR after idle for Power9
From: Jordan Niethe @ 2020-12-07 1:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
In-Reply-To: <20201207010519.15597-1-jniethe5@gmail.com>
On Power9, CIABR is lost after idle. This means that instruction
breakpoints set by xmon which use CIABR do not work. Fix this by
restoring CIABR after idle.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
arch/powerpc/platforms/powernv/idle.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 1ed7c5286487..e6f461812856 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -589,6 +589,7 @@ struct p9_sprs {
u64 spurr;
u64 dscr;
u64 wort;
+ u64 ciabr;
u64 mmcra;
u32 mmcr0;
@@ -668,6 +669,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
sprs.spurr = mfspr(SPRN_SPURR);
sprs.dscr = mfspr(SPRN_DSCR);
sprs.wort = mfspr(SPRN_WORT);
+ sprs.ciabr = mfspr(SPRN_CIABR);
sprs.mmcra = mfspr(SPRN_MMCRA);
sprs.mmcr0 = mfspr(SPRN_MMCR0);
@@ -785,6 +787,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
mtspr(SPRN_SPURR, sprs.spurr);
mtspr(SPRN_DSCR, sprs.dscr);
mtspr(SPRN_WORT, sprs.wort);
+ mtspr(SPRN_CIABR, sprs.ciabr);
mtspr(SPRN_MMCRA, sprs.mmcra);
mtspr(SPRN_MMCR0, sprs.mmcr0);
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/book3s64/kexec: Clear CIABR on kexec
From: Jordan Niethe @ 2020-12-07 1:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
The value in CIABR persists across kexec which can lead to unintended
results when the new kernel hits the old kernel's breakpoint. For
example:
0:mon> bi $loadavg_proc_show
0:mon> b
type address
1 inst c000000000519060 loadavg_proc_show+0x0/0x130
0:mon> x
$ kexec -l /mnt/vmlinux --initrd=/mnt/rootfs.cpio.gz --append='xmon=off'
$ kexec -e
$ cat /proc/loadavg
Trace/breakpoint trap
Make sure CIABR is cleared so this does not happen.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
arch/powerpc/include/asm/book3s/64/kexec.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/kexec.h b/arch/powerpc/include/asm/book3s/64/kexec.h
index 6b5c3a248ba2..d4b9d476ecba 100644
--- a/arch/powerpc/include/asm/book3s/64/kexec.h
+++ b/arch/powerpc/include/asm/book3s/64/kexec.h
@@ -3,6 +3,7 @@
#ifndef _ASM_POWERPC_BOOK3S_64_KEXEC_H_
#define _ASM_POWERPC_BOOK3S_64_KEXEC_H_
+#include <asm/plpar_wrappers.h>
#define reset_sprs reset_sprs
static inline void reset_sprs(void)
@@ -14,6 +15,10 @@ static inline void reset_sprs(void)
if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
mtspr(SPRN_IAMR, 0);
+ if (cpu_has_feature(CPU_FTR_HVMODE))
+ mtspr(SPRN_CIABR, 0);
+ else
+ plpar_set_ciabr(0);
}
/* Do we need isync()? We are going via a kexec reset */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
From: Michael Ellerman @ 2020-12-07 0:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, hch,
viro, akpm
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <e559e60c43f679195bfe4c7b0a301431c6f02c7a.1607157766.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> 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":
>
> [ 1117.202054] ------------[ cut here ]------------
> [ 1117.202102] Bug: fault blocked by AP register !
> [ 1117.202261] WARNING: CPU: 0 PID: 377 at arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
> [ 1117.202310] Modules linked in:
> [ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: G W 5.10.0-rc5-01340-g83f53be2de31-dirty #4175
> [ 1117.202499] NIP: c0012048 LR: c0012048 CTR: 00000000
> [ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: G W (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.202625] MSR: 00021032 <ME,IR,DR,RI> CR: 24082222 XER: 20000000
> [ 1117.202899]
> [ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 00000023 c092e554 00000001 c09865e8 c092e640
> [ 1117.202899] GPR08: 00001032 00000000 00000000 00014efc 28082224 100d166a 100a0920 00000000
> [ 1117.202899] GPR16: 100cac0c 100b0000 1080c3fc 1080d685 100d0000 100d0000 00000000 100a0900
> [ 1117.202899] GPR24: 100d0000 c07892ec 00000000 c0921510 c21f4440 0000005c c0000000 cacdbc80
> [ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204509] Call Trace:
> [ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
> [ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
> [ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 00000001
> [ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: G W (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.205104] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28082224 XER: 00000000
> [ 1117.205416] DAR: 0000005c DSISR: c0000000
> [ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 00000001 00000017 00000017 00000027 0000000f
> [ 1117.205416] GPR08: c09926ec 00000000 00000000 3ffff000 24082224
> [ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
> [ 1117.206258] --- interrupt: 301
> [ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
> [ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
> [ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
> [ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
> [ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
> [ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
> [ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
> [ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
> [ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
> [ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
> [ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
> [ 1117.207938] --- interrupt: c01 at 0xfd4e784
> [ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
> [ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: G W (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.208134] MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 44002222 XER: 00000000
> [ 1117.208470]
> [ 1117.208470] GPR00: 00000004 7fc34090 77bfb4e0 00000001 1080fa40 00000002 7400000f fefefeff
> [ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0 00000000
> [ 1117.209104] NIP [0fd4e784] 0xfd4e784
> [ 1117.209180] LR [0fe0f244] 0xfe0f244
> [ 1117.209236] --- interrupt: c01
> [ 1117.209274] Instruction dump:
> [ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040 4082ff60
> [ 1117.209727] 0fe00000 3c60c082 386399f4 48013b65 <0fe00000> 80010034 3860000b 7c0803a6
> [ 1117.210102] ---[ end trace 1927c0323393af3e ]---
>
> To avoid that, copy_from_kernel_nofault_allowed() is used to check
> whether the address is a valid kernel address. But the default
> version of it returns true for any address.
>
> Provide a powerpc version of copy_from_kernel_nofault_allowed()
> that returns false when the address is below TASK_USER_MAX,
> so that copy_from_kernel_nofault() will return -ERANGE.
>
> Reported-by: Qian Cai <qcai@redhat.com>
> Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> This issue was introduced in 5.10. I didn't mark it for stable, hopping it will go into 5.10-rc7
> ---
> arch/powerpc/mm/Makefile | 2 +-
> arch/powerpc/mm/maccess.c | 9 +++++++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/mm/maccess.c
>
> diff --git a/arch/powerpc/mm/maccess.c b/arch/powerpc/mm/maccess.c
> new file mode 100644
> index 000000000000..56e97c0fb233
> --- /dev/null
> +++ b/arch/powerpc/mm/maccess.c
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/uaccess.h>
> +#include <linux/kernel.h>
> +
> +bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
> +{
> + return (unsigned long)unsafe_src >= TASK_SIZE_MAX;
> +}
Is there a reason we're using TASK_SIZE_MAX?
It's copy from *kernel* (nofault) allowed, so shouldn't we be checking
that the address plausibly points at kernel memory? Not at no-man's land
above TASK_SIZE_MAX but below the start of kernel memory?
We have is_kernel_addr() which already encapsulates some platform quirks
around that logic, it seems like it would be a better fit?
ie:
bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
{
return is_kernel_addr((unsigned long)unsafe_src);
}
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3s_hv_uvmem: Check for failed page migration
From: Alistair Popple @ 2020-12-07 0:13 UTC (permalink / raw)
To: Ram Pai; +Cc: linuxppc-dev, Bharata B Rao
In-Reply-To: <20201204165244.GA3390@ram-ibm-com.ibm.com>
On Saturday, 5 December 2020 3:52:44 AM AEDT Ram Pai wrote:
> On Fri, Dec 04, 2020 at 03:48:41PM +0530, Bharata B Rao wrote:
> > On Thu, Dec 03, 2020 at 04:08:12PM +1100, Alistair Popple wrote:
> This patch certainly looks like the problem, that has been hurting
> us for a while. Let me run this patch through my SVM tests. Looks very
> promising.
>
> BTW: The code does a similar thing while paging out. It pages out from the
> UV, and then does the migration. Is there a bug there aswell?
As specified the migrate_pages_vma() API can fail to migrate device private
pages. However the fix was less obvious to me, and in practice I don't think it
will ever fail for device private pages as you don't have the same races to
establish the page and device private pages can't be pinned.
It might be worth adding some kind of warning though in case this ever
changes.
- Alistair
> RP
>
^ permalink raw reply
* Re: [PATCH] powerpc/book3s_hv_uvmem: Check for failed page migration
From: Alistair Popple @ 2020-12-06 23:55 UTC (permalink / raw)
To: bharata; +Cc: linuxppc-dev, Ram Pai
In-Reply-To: <20201204101841.GA621541@in.ibm.com>
On Friday, 4 December 2020 9:18:41 PM AEDT Bharata B Rao wrote:
>
> Reviewed-by: Bharata B Rao <bharata@linux.ibm.com>
>
> Did you actually hit this scenario with secure VMs where a UV-paged-in
> page was later found to be not migratable?
No, this was found by inspection. I have no way of testing this but we had a
similar issue in Nouveau and I think you would have a similar issue here
although it might be hard to hit.
migrate_vma_pages() will fail a page migration if a CPU thread has raced and
established a non-zero page PTE for the address. See migrate_vma_insert_page()
for the implementation. It will also fail if something else has taken a
reference on the page after calling migrate_vma_setup(), but that is less
likely as any existing pages will have been isolated.
- Alistair
> Regards,
> Bharata.
>
^ permalink raw reply
* RE: [PATCH v5 09/19] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
From: Prabhakar Mahadev Lad @ 2020-12-06 22:09 UTC (permalink / raw)
To: Serge Semin, Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
Greg Kroah-Hartman, Rob Herring, Chunfeng Yun, Yoshihiro Shimoda
Cc: devicetree@vger.kernel.org, Ahmad Zainie,
linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
Neil Armstrong, Martin Blumenstingl, Kevin Hilman,
linux-usb@vger.kernel.org, linux-mips@vger.kernel.org,
Serge Semin, Bjorn Andersson, Manu Gautam, Andy Gross,
Pavel Parkhomenko, Alexey Malahov, linuxppc-dev@lists.ozlabs.org,
Rob Herring, linux-arm-kernel@lists.infradead.org, Roger Quadros
In-Reply-To: <20201205152427.29537-10-Sergey.Semin@baikalelectronics.ru>
Hi Serge,
Thank you for the patch.
> -----Original Message-----
> From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Sent: 05 December 2020 15:24
> To: Mathias Nyman <mathias.nyman@intel.com>; Felipe Balbi <balbi@kernel.org>; Krzysztof Kozlowski
> <krzk@kernel.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob Herring <robh+dt@kernel.org>;
> Chunfeng Yun <chunfeng.yun@mediatek.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-
> lad.rj@bp.renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>; Serge Semin <fancer.lancer@gmail.com>; Alexey
> Malahov <Alexey.Malahov@baikalelectronics.ru>; Pavel Parkhomenko
> <Pavel.Parkhomenko@baikalelectronics.ru>; Andy Gross <agross@kernel.org>; Bjorn Andersson
> <bjorn.andersson@linaro.org>; Manu Gautam <mgautam@codeaurora.org>; Roger Quadros <rogerq@ti.com>;
> Neil Armstrong <narmstrong@baylibre.com>; Kevin Hilman <khilman@baylibre.com>; Martin Blumenstingl
> <martin.blumenstingl@googlemail.com>; Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>; linux-
> arm-kernel@lists.infradead.org; linux-snps-arc@lists.infradead.org; linux-mips@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-usb@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; Rob Herring <robh@kernel.org>
> Subject: [PATCH v5 09/19] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
>
> With minor peculiarities (like uploading some vendor-specific firmware)
> these are just Generic xHCI controllers fully compatible with its
> properties. Make sure the Renesas USB xHCI DT nodes are also validated
> against the Generic xHCI DT schema.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
> b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
> index 0f078bd0a3e5..7e5ed196b52c 100644
> --- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
> +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
> @@ -11,7 +11,7 @@ maintainers:
> - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> allOf:
> - - $ref: "usb-hcd.yaml"
> + - $ref: "usb-xhci.yaml"
>
> properties:
> compatible:
> @@ -69,7 +69,7 @@ required:
> - power-domains
> - resets
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
> examples:
> - |
> --
> 2.29.2
^ 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