* Re: [RESEND, PATCH v13 08/12] soc: mediatek: cmdq: change the type of input parameter
From: Matthias Brugger @ 2019-08-23 12:09 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820084932.22282-9-bibby.hsieh@mediatek.com>
On 20/08/2019 10:49, Bibby Hsieh wrote:
> According to the cmdq hardware design, the subsys is u8,
> the offset is u16 and the event id is u16.
> This patch changes the type of subsys, offset and event id
> to the correct type.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Applied, thanks
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +++++-----
> include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 082b8978651e..7aa0517ff2f3 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> return 0;
> }
>
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> {
> u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> (subsys << CMDQ_SUBSYS_SHIFT);
> @@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> - u32 offset, u32 value, u32 mask)
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask)
> {
> u32 offset_mask = offset;
> int err = 0;
> @@ -161,7 +161,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> u32 arg_b;
>
> @@ -181,7 +181,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
> }
> EXPORT_SYMBOL(cmdq_pkt_wfe);
>
> -int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event)
> +int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> {
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> index 39d813dde4b4..9618debb9ceb 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -66,7 +66,7 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
>
> /**
> * cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
> @@ -78,8 +78,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> - u32 offset, u32 value, u32 mask);
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> + u16 offset, u32 value, u32 mask);
>
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> @@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
>
> /**
> * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> @@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event);
> +int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 07/12] soc: mediatek: cmdq: reorder the parameter
From: Matthias Brugger @ 2019-08-23 12:05 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820084932.22282-8-bibby.hsieh@mediatek.com>
On 20/08/2019 10:49, Bibby Hsieh wrote:
> The order of gce instructions is [subsys offset value]
> so reorder the parameter of cmdq_pkt_write_mask
> and cmdq_pkt_write function.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
applied to v5.3-next/soc
Thanks!
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
> include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index ff9fef5a032b..082b8978651e 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> return 0;
> }
>
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
> {
> u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> (subsys << CMDQ_SUBSYS_SHIFT);
> @@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
> - u32 subsys, u32 offset, u32 mask)
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> + u32 offset, u32 value, u32 mask)
> {
> u32 offset_mask = offset;
> int err = 0;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> index 4e8899972db4..39d813dde4b4 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
> /**
> * cmdq_pkt_write() - append write command to the CMDQ packet
> * @pkt: the CMDQ packet
> - * @value: the specified target register value
> * @subsys: the CMDQ sub system code
> * @offset: register offset from CMDQ sub system
> + * @value: the specified target register value
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
>
> /**
> * cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
> * @pkt: the CMDQ packet
> - * @value: the specified target register value
> * @subsys: the CMDQ sub system code
> * @offset: register offset from CMDQ sub system
> + * @value: the specified target register value
> * @mask: the specified target register mask
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
> - u32 subsys, u32 offset, u32 mask);
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
> + u32 offset, u32 value, u32 mask);
>
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v4 00/18] objtool: Add support for arm64
From: Raphael Gault @ 2019-08-23 12:00 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, linux-arm-kernel, julien.thierry.kdev
In-Reply-To: <20190822195627.mzi3c4sjqnvnzaho@treble>
Hi Josh,
On 8/22/19 8:56 PM, Josh Poimboeuf wrote:
> On Fri, Aug 16, 2019 at 01:23:45PM +0100, Raphael Gault wrote:
>> Hi,
>>
>> Changes since RFC V3:
>> * Rebased on tip/master: Switch/jump table had been refactored
>> * Take Catalin Marinas comments into account regarding the asm macro for
>> marking exceptions.
>>
>> As of now, objtool only supports the x86_64 architecture but the
>> groundwork has already been done in order to add support for other
>> architectures without too much effort.
>>
>> This series of patches adds support for the arm64 architecture
>> based on the Armv8.5 Architecture Reference Manual.
>>
>> Objtool will be a valuable tool to progress and provide more guarentees
>> on live patching which is a work in progress for arm64.
>>
>> Once we have the base of objtool working the next steps will be to
>> port Peter Z's uaccess validation for arm64.
>
> Hi Raphael,
>
> Sorry about the long delay. I have some comments coming shortly.
>
> One general comment: I noticed that several of the (mostly minor)
> suggested changes I made for v1 haven't been fixed.
>
> I'll try to suggest them again here for v4, so you don't need to go back
> and find them. But in the future please try to incorporate all the
> comments from previous patch sets before posting new versions. I'm sure
> it wasn't intentional, as you did acknowledge and agree to most of the
> changes. But it does waste people's time and goodwill if you neglect to
> incorporate their suggestions. Thanks.
>
Indeed, sorry about that.
Thanks for you comments, I will do my best to address them shortly.
However, I won't have access to my professional emails for a little
while and probably won't be able to work on this before at least a week.
I'll try to have a new soon though and use my personal email.
Thanks,
--
Raphael Gault
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 7/7] arm64: smp: add arch specific cpu parking helper
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
Add an arm64 specific helper which parks the cpu in a more architecture
efficient way.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
arch/arm64/kernel/smp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index c7497a885cfd..a3fb22b4c870 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -947,6 +947,12 @@ void tick_broadcast(const struct cpumask *mask)
}
#endif
+void arch_smp_cpu_park(void)
+{
+ while (1)
+ cpu_park_loop();
+}
+
void arch_smp_cpus_stop_complete(void)
{
sdei_mask_local_cpu();
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 6/7] arm64: smp: use SMP crash-stop common code
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
Make arm64 use the SMP common implementation of crash_smp_send_stop() and
its generic logic, by removing the arm64 crash_smp_send_stop() definition
and providing the needed arch specific helpers.
Additionally, simplify the arch-specific stop and crash dump ISRs backends
(which are in charge of effectively receiving and interpreting the
stop/crash messages) and unify them as much as possible.
Using the SMP common code, it is no more needed to make use of an atomic_t
counter to make sure that each CPU had time to perform its crash dump
related shutdown-ops before the world ends: simply take care to synchronize
on cpu_online_mask, and add proper explicit memory barriers where needed.
Moreover, remove arm64 specific smp_crash_stop_failed() helper as a whole
and rely on the common code provided homonym function to lookup the state
of an ongoing crash_stop operation.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
arch/arm64/include/asm/smp.h | 2 -
arch/arm64/kernel/smp.c | 100 +++++++++--------------------------
2 files changed, 26 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index a0c8a0b65259..d98c409f9225 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -150,8 +150,6 @@ static inline void cpu_panic_kernel(void)
*/
bool cpus_are_stuck_in_kernel(void);
-extern void crash_smp_send_stop(void);
-extern bool smp_crash_stop_failed(void);
#endif /* ifndef __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 473be3c23df7..c7497a885cfd 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -825,12 +825,30 @@ void arch_irq_work_raise(void)
}
#endif
-static void local_cpu_stop(void)
+static void local_cpu_crash_or_stop(struct pt_regs *crash_regs)
{
- set_cpu_online(smp_processor_id(), false);
+ unsigned int cpu = smp_processor_id();
- local_daif_mask();
+ if (IS_ENABLED(CONFIG_KEXEC_CORE) && crash_regs) {
+#ifdef CONFIG_KEXEC_CORE
+ /* crash stop requested: save regs before going offline */
+ crash_save_cpu(crash_regs, cpu);
+#endif
+ local_irq_disable();
+ } else {
+ local_daif_mask();
+ }
sdei_mask_local_cpu();
+ /* ensure dumped regs are visible once cpu is seen offline */
+ smp_wmb();
+ set_cpu_online(cpu, false);
+ /* ensure all writes are globally visible before cpu parks */
+ wmb();
+#if defined(CONFIG_KEXEC_CORE) && defined(CONFIG_HOTPLUG_CPU)
+ if (cpu_ops[cpu]->cpu_die)
+ cpu_ops[cpu]->cpu_die(cpu);
+#endif
+ /* just in case */
cpu_park_loop();
}
@@ -841,31 +859,7 @@ static void local_cpu_stop(void)
*/
void panic_smp_self_stop(void)
{
- local_cpu_stop();
-}
-
-#ifdef CONFIG_KEXEC_CORE
-static atomic_t waiting_for_crash_ipi = ATOMIC_INIT(0);
-#endif
-
-static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs)
-{
-#ifdef CONFIG_KEXEC_CORE
- crash_save_cpu(regs, cpu);
-
- atomic_dec(&waiting_for_crash_ipi);
-
- local_irq_disable();
- sdei_mask_local_cpu();
-
-#ifdef CONFIG_HOTPLUG_CPU
- if (cpu_ops[cpu]->cpu_die)
- cpu_ops[cpu]->cpu_die(cpu);
-#endif
-
- /* just in case */
- cpu_park_loop();
-#endif
+ local_cpu_crash_or_stop(NULL);
}
/*
@@ -894,14 +888,14 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
case IPI_CPU_STOP:
irq_enter();
- local_cpu_stop();
+ local_cpu_crash_or_stop(NULL);
irq_exit();
break;
case IPI_CPU_CRASH_STOP:
if (IS_ENABLED(CONFIG_KEXEC_CORE)) {
irq_enter();
- ipi_cpu_crash_stop(cpu, regs);
+ local_cpu_crash_or_stop(regs);
unreachable();
}
@@ -963,52 +957,10 @@ void arch_smp_stop_call(cpumask_t *cpus)
smp_cross_call(cpus, IPI_CPU_STOP);
}
-#ifdef CONFIG_KEXEC_CORE
-void crash_smp_send_stop(void)
+void arch_smp_crash_call(cpumask_t *cpus)
{
- static int cpus_stopped;
- cpumask_t mask;
- unsigned long timeout;
-
- /*
- * This function can be called twice in panic path, but obviously
- * we execute this only once.
- */
- if (cpus_stopped)
- return;
-
- cpus_stopped = 1;
-
- if (num_online_cpus() == 1) {
- sdei_mask_local_cpu();
- return;
- }
-
- cpumask_copy(&mask, cpu_online_mask);
- cpumask_clear_cpu(smp_processor_id(), &mask);
-
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
-
- pr_crit("SMP: stopping secondary CPUs\n");
- smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
-
- /* Wait up to one second for other CPUs to stop */
- timeout = USEC_PER_SEC;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
- udelay(1);
-
- if (atomic_read(&waiting_for_crash_ipi) > 0)
- pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
- cpumask_pr_args(&mask));
-
- sdei_mask_local_cpu();
-}
-
-bool smp_crash_stop_failed(void)
-{
- return (atomic_read(&waiting_for_crash_ipi) > 0);
+ smp_cross_call(cpus, IPI_CPU_CRASH_STOP);
}
-#endif
/*
* not supported here
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 5/7] arm64: smp: use generic SMP stop common code
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
Make arm64 use the generic SMP-stop logic provided by common code
unified smp_send_stop() function.
arm64 smp_send_stop() logic had a bug in it: it failed to consider the
online status of the calling CPU when evaluating if any stop message
needed to be sent to other CPus at all: this resulted, on a 2-CPUs
system, in the failure to stop all cpus if one paniced while starting
up, leaving such system in an unexpected lively state.
[root@arch ~]# echo 1 > /sys/devices/system/cpu/cpu1/online
[root@arch ~]# [ 152.583368] ------------[ cut here ]------------
[ 152.583872] kernel BUG at arch/arm64/kernel/cpufeature.c:852!
[ 152.584693] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 152.585228] Modules linked in:
[ 152.586040] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.3.0-rc5-00001-gcabd12118c4a-dirty #2
[ 152.586218] Hardware name: Foundation-v8A (DT)
[ 152.586478] pstate: 000001c5 (nzcv dAIF -PAN -UAO)
[ 152.587260] pc : has_cpuid_feature+0x35c/0x360
[ 152.587398] lr : verify_local_elf_hwcaps+0x6c/0xf0
[ 152.587520] sp : ffff0000118bbf60
[ 152.587605] x29: ffff0000118bbf60 x28: 0000000000000000
[ 152.587784] x27: 0000000000000000 x26: 0000000000000000
[ 152.587882] x25: ffff00001167a010 x24: ffff0000112f59f8
[ 152.587992] x23: 0000000000000000 x22: 0000000000000000
[ 152.588085] x21: ffff0000112ea018 x20: ffff000010fe5518
[ 152.588180] x19: ffff000010ba3f30 x18: 0000000000000036
[ 152.588285] x17: 0000000000000000 x16: 0000000000000000
[ 152.588380] x15: 0000000000000000 x14: ffff80087a821210
[ 152.588481] x13: 0000000000000000 x12: 0000000000000000
[ 152.588599] x11: 0000000000000080 x10: 00400032b5503510
[ 152.588709] x9 : 0000000000000000 x8 : ffff000010b93204
[ 152.588810] x7 : 00000000800001d8 x6 : 0000000000000005
[ 152.588910] x5 : 0000000000000000 x4 : 0000000000000000
[ 152.589021] x3 : 0000000000000000 x2 : 0000000000008000
[ 152.589121] x1 : 0000000000180480 x0 : 0000000000180480
[ 152.589379] Call trace:
[ 152.589646] has_cpuid_feature+0x35c/0x360
[ 152.589763] verify_local_elf_hwcaps+0x6c/0xf0
[ 152.589858] check_local_cpu_capabilities+0x88/0x118
[ 152.589968] secondary_start_kernel+0xc4/0x168
[ 152.590530] Code: d53801e0 17ffff58 d5380600 17ffff56 (d4210000)
[ 152.592215] ---[ end trace 80ea98416149c87e ]---
[ 152.592734] Kernel panic - not syncing: Attempted to kill the idle task!
[ 152.593173] Kernel Offset: disabled
[ 152.593501] CPU features: 0x0004,20c02008
[ 152.593678] Memory Limit: none
[ 152.594208] ---[ end Kernel panic - not syncing: Attempted to kill the idle
task! ]---
[root@arch ~]# bash: echo: write error: Input/output error
[root@arch ~]#
[root@arch ~]#
[root@arch ~]# echo HELO
HELO
Get rid of such bug, switching arm64 to use the common SMP stop code.
Reported-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
arch/arm64/Kconfig | 3 +++
arch/arm64/kernel/smp.c | 29 ++++++-----------------------
2 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..3baa69ca4c55 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -276,6 +276,9 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
config SMP
def_bool y
+config ARCH_USE_COMMON_SMP_STOP
+ def_bool y if SMP
+
config KERNEL_MODE_NEON
def_bool y
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 018a33e01b0e..473be3c23df7 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -953,33 +953,16 @@ void tick_broadcast(const struct cpumask *mask)
}
#endif
-void smp_send_stop(void)
+void arch_smp_cpus_stop_complete(void)
{
- unsigned long timeout;
-
- if (num_online_cpus() > 1) {
- cpumask_t mask;
-
- cpumask_copy(&mask, cpu_online_mask);
- cpumask_clear_cpu(smp_processor_id(), &mask);
-
- if (system_state <= SYSTEM_RUNNING)
- pr_crit("SMP: stopping secondary CPUs\n");
- smp_cross_call(&mask, IPI_CPU_STOP);
- }
-
- /* Wait up to one second for other CPUs to stop */
- timeout = USEC_PER_SEC;
- while (num_online_cpus() > 1 && timeout--)
- udelay(1);
-
- if (num_online_cpus() > 1)
- pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
- cpumask_pr_args(cpu_online_mask));
-
sdei_mask_local_cpu();
}
+void arch_smp_stop_call(cpumask_t *cpus)
+{
+ smp_cross_call(cpus, IPI_CPU_STOP);
+}
+
#ifdef CONFIG_KEXEC_CORE
void crash_smp_send_stop(void)
{
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 4/7] smp: address races of starting CPUs while stopping
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
Add to SMP stop common code a best-effort retry logic, re-issuing a stop
request when any CPU is detected to be still online after the first
stop request cycle has completed.
Address the case in which some CPUs could be still starting up when the
stop process is started, remaining so undetected and coming fully online
only after the SMP stop procedure was already started: such officially
still offline CPUs would be missed by an ongoing stop procedure.
(not considering here the special case of stuck CPUs)
Using here a best effort approach, though, it is not anyway guaranteed
to be able to stop any CPU that happened to finally come online after
the whole SMP stop retry cycle has completed.
(i.e. the race-window is reduced but not eliminated)
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
A more deterministic approach has been also attempted in order to catch
any concurrently starting CPUs at the very last moment and make them
kill themselves by:
- adding a new set_cpus_stopping() in cpumask.h used to set a
__cpus_stopping atomic internal flag
- modifying set_cpu_online() to check on __cpus_stopping only when
coming online, and force the offending CPU to kill itself in that case
Anyway it has proved tricky and complex (beside faulty) to implement the
above 'kill-myself' phase in a reliable way while remaining architecture
agnostic and still distingushing properly regular stops from crash kexec.
So given that the main idea underlying this patch series was instead of
simplifying and unifying code and the residual races not caught by the
best-effort logic seemed not very likely, this more deterministic approach
has been dropped in favour of the best effort retry logic.
---
kernel/smp.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index ea8a1cc0ec3e..10d3120494f2 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -847,6 +847,8 @@ void __weak arch_smp_crash_call(cpumask_t *cpus)
#define REASON_STOP 1
#define REASON_CRASH 2
+#define MAX_STOP_RETRIES 2
+
/*
* This centralizes the common logic to:
*
@@ -860,7 +862,7 @@ void __weak arch_smp_crash_call(cpumask_t *cpus)
*/
static inline void __smp_send_stop_all(bool reason_crash)
{
- unsigned int this_cpu_id;
+ unsigned int this_cpu_id, retries = MAX_STOP_RETRIES;
cpumask_t mask;
static atomic_t stopping;
int was_reason;
@@ -894,7 +896,7 @@ static inline void __smp_send_stop_all(bool reason_crash)
arch_smp_cpu_park();
}
}
- if (any_other_cpus_online(&mask, this_cpu_id)) {
+ while (retries-- && any_other_cpus_online(&mask, this_cpu_id)) {
unsigned long timeout;
unsigned int this_cpu_online = cpu_online(this_cpu_id);
@@ -921,9 +923,12 @@ static inline void __smp_send_stop_all(bool reason_crash)
udelay(1);
/* ensure any stopping-CPUs memory access is made visible */
smp_rmb();
- if (num_online_cpus() > this_cpu_online)
+ if (num_online_cpus() > this_cpu_online) {
pr_warn("failed to stop secondary CPUs %*pbl\n",
cpumask_pr_args(cpu_online_mask));
+ if (retries)
+ pr_warn("Retrying SMP stop call...\n");
+ }
}
/* Perform final (possibly arch-specific) work on this CPU */
arch_smp_cpus_stop_complete();
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 3/7] smp: coordinate concurrent crash/smp stop calls
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
Once a stop request is in progress on one CPU, it must be carefully
evaluated what to do if another stop request is issued concurrently
on another CPU.
Given that panic and crash dump code flows are mutually exclusive,
the only alternative possible scenario which instead could lead to
concurrent stop requests, is represented by the simultaneous stop
requests possibly triggered by a concurrent halt/reboot/shutdown.
In such a case, prioritize the panic/crash procedure and most importantly
immediately park the offending CPU that was attempting the concurrent stop
request: force it to idle quietly, waiting for the ongoing stop/dump
requests to arrive.
Failing to do so would result in the offending CPU being effectively lost
on the next possible reboot triggered by the crash dump. [1]
Another scenario, where the crash/stop code path was known to be executed
twice, was during a normal panic/crash with crash_kexec_post_notifiers=1;
since this issue is similar, fold also this case-handling into this new
logic.
[1]
<<<<<---------- TRIGGERED PANIC
[ 225.676014] ------------[ cut here ]------------
[ 225.676656] kernel BUG at arch/arm64/kernel/cpufeature.c:852!
[ 225.677253] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 225.677660] Modules linked in:
[ 225.678458] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.3.0-rc5-00004-gb8a210cd3c32-dirty #2
[ 225.678621] Hardware name: Foundation-v8A (DT)
[ 225.678868] pstate: 000001c5 (nzcv dAIF -PAN -UAO)
[ 225.679523] pc : has_cpuid_feature+0x35c/0x360
[ 225.679649] lr : verify_local_elf_hwcaps+0x6c/0xf0
[ 225.679759] sp : ffff0000118cbf60
[ 225.679855] x29: ffff0000118cbf60 x28: 0000000000000000
[ 225.680026] x27: 0000000000000000 x26: 0000000000000000
[ 225.680115] x25: ffff00001167a010 x24: ffff0000112f59f8
[ 225.680207] x23: 0000000000000000 x22: 0000000000000000
[ 225.680290] x21: ffff0000112ea018 x20: ffff000010fe5538
[ 225.680372] x19: ffff000010ba3f30 x18: 000000000000001e
[ 225.680465] x17: 0000000000000000 x16: 0000000000000000
[ 225.680546] x15: 0000000000000000 x14: 0000000000000008
[ 225.680629] x13: 0209018b7a9404f4 x12: 0000000000000001
[ 225.680719] x11: 0000000000000080 x10: 00400032b5503510
[ 225.680803] x9 : 0000000000000000 x8 : ffff000010b93204
[ 225.680884] x7 : 00000000800001d8 x6 : 0000000000000005
[ 225.680975] x5 : 0000000000000000 x4 : 0000000000000000
[ 225.681056] x3 : 0000000000000000 x2 : 0000000000008000
[ 225.681139] x1 : 0000000000180480 x0 : 0000000000180480
[ 225.681423] Call trace:
[ 225.681669] has_cpuid_feature+0x35c/0x360
[ 225.681762] verify_local_elf_hwcaps+0x6c/0xf0
[ 225.681836] check_local_cpu_capabilities+0x88/0x118
[ 225.681939] secondary_start_kernel+0xc4/0x168
[ 225.682432] Code: d53801e0 17ffff58 d5380600 17ffff56 (d4210000)
[ 225.683998] smp: stopping secondary CPUs
[ 225.684130] Delaying stop.... <<<<<------ INSTRUMENTED DEBUG_DELAY
Rebooting. <<<<<------ MANUAL SIMULTANEOUS REBOOT
[ 232.647472] reboot: Restarting system
[ 232.648363] Reboot failed -- System halted
[ 239.552413] smp: failed to stop secondary CPUs 0
[ 239.554730] Starting crashdump kernel...
[ 239.555194] ------------[ cut here ]------------
[ 239.555406] Some CPUs may be stale, kdump will be unreliable.
[ 239.555802] WARNING: CPU: 3 PID: 0 at arch/arm64/kernel/machine_kexec.c:156 machine_kexec+0x3c/0x2b0
[ 239.556044] Modules linked in:
[ 239.556244] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.3.0-rc5-00004-gb8a210cd3c32-dirty #2
[ 239.556340] Hardware name: Foundation-v8A (DT)
[ 239.556459] pstate: 600003c5 (nZCv DAIF -PAN -UAO)
[ 239.556587] pc : machine_kexec+0x3c/0x2b0
[ 239.556700] lr : machine_kexec+0x3c/0x2b0
[ 239.556775] sp : ffff0000118cbad0
[ 239.556876] x29: ffff0000118cbad0 x28: ffff80087a8c3700
[ 239.557012] x27: 0000000000000000 x26: 0000000000000000
[ 239.557278] x25: ffff000010fe3ef0 x24: 00000000000003c0
....
[ 239.561568] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0000000003 [0x410fd0f0]
[ 0.000000] Linux version 5.2.0-rc4-00001-g93bd4bc234d5-dirty
[ 0.000000] Machine model: Foundation-v8A
...
[ 0.197991] smp: Bringing up secondary CPUs ...
[ 0.232643] psci: failed to boot CPU1 (-22) <<<<--- LOST CPU ON REBOOT
[ 0.232861] CPU1: failed to boot: -22
[ 0.306291] Detected PIPT I-cache on CPU2
[ 0.310524] GICv3: CPU2: found redistributor 1 region 0:0x000000002f120000
[ 0.315618] CPU2: Booted secondary processor 0x0000000001 [0x410fd0f0]
[ 0.395576] Detected PIPT I-cache on CPU3
[ 0.400431] GICv3: CPU3: found redistributor 2 region 0:0x000000002f140000
[ 0.407252] CPU3: Booted secondary processor 0x0000000002 [0x410fd0f0]
[ 0.431811] smp: Brought up 1 node, 3 CPUs
[ 0.439898] SMP: Total of 3 processors activated.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
include/linux/smp.h | 3 +++
kernel/smp.c | 48 ++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 21c97c175dad..781b18b7fec0 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -104,6 +104,9 @@ extern void arch_smp_crash_call(cpumask_t *cpus);
/* Helper to query the outcome of an ongoing crash_stop operation */
bool smp_crash_stop_failed(void);
+
+/* A generic cpu parking helper, possibly overridden by architecture code */
+void arch_smp_cpu_park(void) __noreturn;
#endif
/*
diff --git a/kernel/smp.c b/kernel/smp.c
index 31e981eb9bd8..ea8a1cc0ec3e 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -821,6 +821,12 @@ EXPORT_SYMBOL_GPL(smp_call_on_cpu);
#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+void __weak arch_smp_cpu_park(void)
+{
+ while (1)
+ cpu_relax();
+}
+
void __weak arch_smp_cpus_stop_complete(void) { }
static inline bool any_other_cpus_online(cpumask_t *mask,
@@ -838,6 +844,9 @@ void __weak arch_smp_crash_call(cpumask_t *cpus)
arch_smp_stop_call(cpus);
}
+#define REASON_STOP 1
+#define REASON_CRASH 2
+
/*
* This centralizes the common logic to:
*
@@ -853,8 +862,38 @@ static inline void __smp_send_stop_all(bool reason_crash)
{
unsigned int this_cpu_id;
cpumask_t mask;
+ static atomic_t stopping;
+ int was_reason;
this_cpu_id = smp_processor_id();
+ /* make sure that concurrent stop requests are handled properly */
+ was_reason = atomic_cmpxchg(&stopping, 0,
+ reason_crash ? REASON_CRASH : REASON_STOP);
+ if (was_reason) {
+ /*
+ * This function can be called twice in panic path if
+ * crash_kexec is called with crash_kexec_post_notifiers=1,
+ * but obviously we execute this only once.
+ */
+ if (reason_crash && was_reason == REASON_CRASH)
+ return;
+ /*
+ * In case of other concurrent STOP calls (like in a REBOOT
+ * started simultaneously as an ongoing PANIC/CRASH/REBOOT)
+ * we want to prioritize the ongoing PANIC/KEXEC call and
+ * force here the offending CPU that was attempting the
+ * concurrent STOP to just sit idle waiting to die.
+ * Failing to do so would result in a lost CPU on the next
+ * possible reboot triggered by crash_kexec().
+ */
+ if (!reason_crash) {
+ pr_crit("CPU%d - kernel already stopping, parking myself.\n",
+ this_cpu_id);
+ local_irq_enable();
+ /* does not return */
+ arch_smp_cpu_park();
+ }
+ }
if (any_other_cpus_online(&mask, this_cpu_id)) {
unsigned long timeout;
unsigned int this_cpu_online = cpu_online(this_cpu_id);
@@ -915,6 +954,9 @@ bool __weak smp_crash_stop_failed(void)
*/
void __weak crash_smp_send_stop(void)
{
+#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+ __smp_send_stop_all(true);
+#else
static int cpus_stopped;
/*
@@ -924,11 +966,7 @@ void __weak crash_smp_send_stop(void)
if (cpus_stopped)
return;
-#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
- __smp_send_stop_all(true);
-#else
smp_send_stop();
-#endif
-
cpus_stopped = 1;
+#endif
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 2/7] smp: unify crash_ and smp_send_stop() logic
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
crash_smp_send_stop() logic was fairly similar to smp_send_stop():
a lot of logic and code was duplicated between the two code paths and
across a few different architectures.
Unify this underlying common logic into the existing SMP common stop
code: use a common workhorse function for both paths to perform the
common tasks while taking care to propagate to the underlying
architecture code the intent of the stop operation: a simple stop or
a crash dump stop.
Relocate the __weak crash_smp_send_stop() function from panic.c to smp.c,
since it is the crash dump entry point for the crash stop process and now
calls into this new common logic (only if this latter is enabled by
ARCH_USE_COMMON_SMP_STOP=y).
Introduce a few more helpers so that the architectures willing to use
the common code logic can provide their arch-specific bits to handle
the differences between a stop and a crash stop; architectures can
anyway decide to override as a whole the common logic providing their
own custom solution in crash_smp_send_stop() (as it was before).
Provide also a new common code method to inquiry on the outcome of an
ongoing crash_stop procedure: smp_crash_stop_failed().
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
include/linux/smp.h | 25 +++++++++++++++++++
kernel/panic.c | 26 --------------------
kernel/smp.c | 58 ++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 80 insertions(+), 29 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 0fea0e6d2339..21c97c175dad 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -91,8 +91,27 @@ extern void arch_smp_stop_call(cpumask_t *cpus);
* the local CPU once the other CPUs have been successfully stopped.
*/
void arch_smp_cpus_stop_complete(void);
+
+/*
+ * An Architecture CAN additionally provide the arch_smp_crash_call()
+ * helper which implements the arch-specific crash dump related operations.
+ *
+ * If such arch wants to fully support crash dump, this MUST be provided;
+ * when not provided the crash dump procedure will fallback to behave like
+ * a normal stop. (no saved regs, no arch-specific features disabled)
+ */
+extern void arch_smp_crash_call(cpumask_t *cpus);
+
+/* Helper to query the outcome of an ongoing crash_stop operation */
+bool smp_crash_stop_failed(void);
#endif
+/*
+ * stops all CPUs but the current one propagating to all other CPUs
+ * the information that a crash_kexec is ongoing:
+ */
+void crash_smp_send_stop(void);
+
/*
* sends a 'reschedule' event to another CPU:
*/
@@ -156,6 +175,12 @@ static inline int get_boot_cpu_id(void)
static inline void smp_send_stop(void) { }
+static inline void crash_smp_send_stop(void) { }
+
+#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+static inline bool smp_crash_stop_failed(void) { }
+#endif
+
/*
* These macros fold the SMP functionality into a single CPU system
*/
diff --git a/kernel/panic.c b/kernel/panic.c
index 057540b6eee9..bc0dbf9c9b75 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -86,32 +86,6 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
panic_smp_self_stop();
}
-/*
- * Stop other CPUs in panic. Architecture dependent code may override this
- * with more suitable version. For example, if the architecture supports
- * crash dump, it should save registers of each stopped CPU and disable
- * per-CPU features such as virtualization extensions.
- */
-void __weak crash_smp_send_stop(void)
-{
- static int cpus_stopped;
-
- /*
- * This function can be called twice in panic path, but obviously
- * we execute this only once.
- */
- if (cpus_stopped)
- return;
-
- /*
- * Note smp_send_stop is the usual smp shutdown function, which
- * unfortunately means it may not be hardened to work in a panic
- * situation.
- */
- smp_send_stop();
- cpus_stopped = 1;
-}
-
atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
/*
diff --git a/kernel/smp.c b/kernel/smp.c
index 700502ee2546..31e981eb9bd8 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -820,6 +820,7 @@ int smp_call_on_cpu(unsigned int cpu, int (*func)(void *), void *par, bool phys)
EXPORT_SYMBOL_GPL(smp_call_on_cpu);
#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+
void __weak arch_smp_cpus_stop_complete(void) { }
static inline bool any_other_cpus_online(cpumask_t *mask,
@@ -831,6 +832,12 @@ static inline bool any_other_cpus_online(cpumask_t *mask,
return !cpumask_empty(mask);
}
+void __weak arch_smp_crash_call(cpumask_t *cpus)
+{
+ pr_debug("SMP: Using generic %s() as SMP crash call.\n", __func__);
+ arch_smp_stop_call(cpus);
+}
+
/*
* This centralizes the common logic to:
*
@@ -842,7 +849,7 @@ static inline bool any_other_cpus_online(cpumask_t *mask,
* - wait for the stop operation to be completed across all involved CPUs
* monitoring the cpu_online_mask
*/
-void smp_send_stop(void)
+static inline void __smp_send_stop_all(bool reason_crash)
{
unsigned int this_cpu_id;
cpumask_t mask;
@@ -854,8 +861,11 @@ void smp_send_stop(void)
if (system_state <= SYSTEM_RUNNING)
pr_crit("stopping secondary CPUs\n");
- arch_smp_stop_call(&mask);
-
+ /* smp and crash arch-backends helpers are kept distinct */
+ if (!reason_crash)
+ arch_smp_stop_call(&mask);
+ else
+ arch_smp_crash_call(&mask);
/*
* Wait up to one second for other CPUs to stop.
*
@@ -879,4 +889,46 @@ void smp_send_stop(void)
/* Perform final (possibly arch-specific) work on this CPU */
arch_smp_cpus_stop_complete();
}
+
+void smp_send_stop(void)
+{
+ __smp_send_stop_all(false);
+}
+
+bool __weak smp_crash_stop_failed(void)
+{
+ return (num_online_cpus() > cpu_online(smp_processor_id()));
+}
+#endif
+
+/*
+ * Stop other CPUs while passing down the additional information that a
+ * crash_kexec is ongoing: it's up to the architecture implementation
+ * decide what to do.
+ *
+ * For example, Architectures supporting crash dump should provide
+ * specialized support for saving registers and disabling per-CPU features
+ * like virtualization extensions.
+ *
+ * Behaviour in the CONFIG_ARCH_USE_COMMON_SMP_STOP=n case is preserved
+ * as it was before.
+ */
+void __weak crash_smp_send_stop(void)
+{
+ static int cpus_stopped;
+
+ /*
+ * This function can be called twice in panic path, but obviously
+ * we execute this only once.
+ */
+ if (cpus_stopped)
+ return;
+
+#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+ __smp_send_stop_all(true);
+#else
+ smp_send_stop();
#endif
+
+ cpus_stopped = 1;
+}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 0/7] Unify SMP stop generic logic to common code
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
Hi all,
the logic underlying SMP stop and kexec crash procedures, beside containing
some arch-specific bits, is mostly generic and common across all archs:
despite this fact, such logic is now scattered across all architectures and
on some of them is flawed, in such a way that, under some specific
conditions, you can end up with a CPU left still running after a panic and
possibly lost across a subsequent kexec crash reboot. [1]
Beside the flaws on some archs, there is anyway lots of code duplication,
so this patch series attempts to move into common code all the generic SMP
stop and crash logic, fixing observed issues, and leaving only the arch
specific bits inside properly provided arch-specific helpers.
An architecture willing to rely on this SMP common logic has to define its
own helpers and set CONFIG_ARCH_USE_COMMON_SMP_STOP=y.
The series wire this up for arm64.
Behaviour is not changed for architectures not adopting this new common
logic.
Tested as follows:
- arm64:
1. boot/reboot
2. panic on a starting CPU within a 2 CPUs system (freezing properly)
3. kexec reboot after a panic like 2. (not losing any CPU on reboot)
4. kexec reboot after a panic like 2. and a simultaneous reboot
(instrumenting code to delay the stop messages transmission
to have time to inject a reboot -f)
- x86:
1. boot/reboot
2. panic
3. kexec crash
Thanks
Cristian
[1]
[root@arch ~]# echo 1 > /sys/devices/system/cpu/cpu1/online
[root@arch ~]# [ 152.583368] ------------[ cut here ]------------
[ 152.583872] kernel BUG at arch/arm64/kernel/cpufeature.c:852!
[ 152.584693] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 152.585228] Modules linked in:
[ 152.586040] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.3.0-rc5-00001-gcabd12118c4a-dirty #2
[ 152.586218] Hardware name: Foundation-v8A (DT)
[ 152.586478] pstate: 000001c5 (nzcv dAIF -PAN -UAO)
[ 152.587260] pc : has_cpuid_feature+0x35c/0x360
[ 152.587398] lr : verify_local_elf_hwcaps+0x6c/0xf0
[ 152.587520] sp : ffff0000118bbf60
[ 152.587605] x29: ffff0000118bbf60 x28: 0000000000000000
[ 152.587784] x27: 0000000000000000 x26: 0000000000000000
[ 152.587882] x25: ffff00001167a010 x24: ffff0000112f59f8
[ 152.587992] x23: 0000000000000000 x22: 0000000000000000
[ 152.588085] x21: ffff0000112ea018 x20: ffff000010fe5518
[ 152.588180] x19: ffff000010ba3f30 x18: 0000000000000036
[ 152.588285] x17: 0000000000000000 x16: 0000000000000000
[ 152.588380] x15: 0000000000000000 x14: ffff80087a821210
[ 152.588481] x13: 0000000000000000 x12: 0000000000000000
[ 152.588599] x11: 0000000000000080 x10: 00400032b5503510
[ 152.588709] x9 : 0000000000000000 x8 : ffff000010b93204
[ 152.588810] x7 : 00000000800001d8 x6 : 0000000000000005
[ 152.588910] x5 : 0000000000000000 x4 : 0000000000000000
[ 152.589021] x3 : 0000000000000000 x2 : 0000000000008000
[ 152.589121] x1 : 0000000000180480 x0 : 0000000000180480
[ 152.589379] Call trace:
[ 152.589646] has_cpuid_feature+0x35c/0x360
[ 152.589763] verify_local_elf_hwcaps+0x6c/0xf0
[ 152.589858] check_local_cpu_capabilities+0x88/0x118
[ 152.589968] secondary_start_kernel+0xc4/0x168
[ 152.590530] Code: d53801e0 17ffff58 d5380600 17ffff56 (d4210000)
[ 152.592215] ---[ end trace 80ea98416149c87e ]---
[ 152.592734] Kernel panic - not syncing: Attempted to kill the idle task!
[ 152.593173] Kernel Offset: disabled
[ 152.593501] CPU features: 0x0004,20c02008
[ 152.593678] Memory Limit: none
[ 152.594208] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[root@arch ~]# bash: echo: write error: Input/output error
[root@arch ~]#
[root@arch ~]#
[root@arch ~]# echo HELO
HELO
Cristian Marussi (7):
smp: add generic SMP-stop support to common code
smp: unify crash_ and smp_send_stop() logic
smp: coordinate concurrent crash/smp stop calls
smp: address races of starting CPUs while stopping
arm64: smp: use generic SMP stop common code
arm64: smp: use SMP crash-stop common code
arm64: smp: add arch specific cpu parking helper
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/smp.h | 2 -
arch/arm64/kernel/smp.c | 127 ++++++++--------------------
include/linux/smp.h | 44 ++++++++++
kernel/panic.c | 26 ------
kernel/smp.c | 158 +++++++++++++++++++++++++++++++++++
6 files changed, 239 insertions(+), 121 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 1/7] smp: add generic SMP-stop support to common code
From: Cristian Marussi @ 2019-08-23 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mark.rutland, peterz, catalin.marinas,
takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>
There was a lot of code duplication across architectures regarding the
SMP stop procedures' logic; moreover some of this duplicated code logic
happened to be similarly faulty across a few architectures: while fixing
such logic, move such generic logic as much as possible inside common
code.
Collect all the common logic related to SMP stop operations into the
common SMP code; any architecture willing to use such centralized logic
can select CONFIG_ARCH_USE_COMMON_STOP=y and provide the related
arch-specific helpers: in such a scenario, those architectures will
transparently start using the common code provided by smp_send_stop()
common function.
On the other side, Architectures not willing to use common code SMP stop
logic will simply leave CONFIG_ARCH_USE_COMMON_STOP undefined and carry
on executing their local arch-specific smp_send_stop() as before.
Suggested-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
include/linux/smp.h | 16 ++++++++++++
kernel/smp.c | 63 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 6fc856c9eda5..0fea0e6d2339 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -77,6 +77,22 @@ int smp_call_function_single_async(int cpu, call_single_data_t *csd);
*/
extern void smp_send_stop(void);
+#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+/*
+ * Any Architecture willing to use STOP common logic implementation
+ * MUST at least provide the arch_smp_stop_call() helper which is in
+ * charge of its own arch-specific CPU-stop mechanism.
+ */
+extern void arch_smp_stop_call(cpumask_t *cpus);
+
+/*
+ * An Architecture CAN also provide the arch_smp_cpus_stop_complete()
+ * dedicated helper, to perform any final arch-specific operation on
+ * the local CPU once the other CPUs have been successfully stopped.
+ */
+void arch_smp_cpus_stop_complete(void);
+#endif
+
/*
* sends a 'reschedule' event to another CPU:
*/
diff --git a/kernel/smp.c b/kernel/smp.c
index 7dbcb402c2fc..700502ee2546 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -20,6 +20,7 @@
#include <linux/sched.h>
#include <linux/sched/idle.h>
#include <linux/hypervisor.h>
+#include <linux/delay.h>
#include "smpboot.h"
@@ -817,3 +818,65 @@ int smp_call_on_cpu(unsigned int cpu, int (*func)(void *), void *par, bool phys)
return sscs.ret;
}
EXPORT_SYMBOL_GPL(smp_call_on_cpu);
+
+#ifdef CONFIG_ARCH_USE_COMMON_SMP_STOP
+void __weak arch_smp_cpus_stop_complete(void) { }
+
+static inline bool any_other_cpus_online(cpumask_t *mask,
+ unsigned int this_cpu_id)
+{
+ cpumask_copy(mask, cpu_online_mask);
+ cpumask_clear_cpu(this_cpu_id, mask);
+
+ return !cpumask_empty(mask);
+}
+
+/*
+ * This centralizes the common logic to:
+ *
+ * - evaluate which CPUs are online and needs to be notified for stop,
+ * while considering properly the status of the calling CPU
+ *
+ * - call the arch-specific helpers to request the effective stop
+ *
+ * - wait for the stop operation to be completed across all involved CPUs
+ * monitoring the cpu_online_mask
+ */
+void smp_send_stop(void)
+{
+ unsigned int this_cpu_id;
+ cpumask_t mask;
+
+ this_cpu_id = smp_processor_id();
+ if (any_other_cpus_online(&mask, this_cpu_id)) {
+ unsigned long timeout;
+ unsigned int this_cpu_online = cpu_online(this_cpu_id);
+
+ if (system_state <= SYSTEM_RUNNING)
+ pr_crit("stopping secondary CPUs\n");
+ arch_smp_stop_call(&mask);
+
+ /*
+ * Wait up to one second for other CPUs to stop.
+ *
+ * Here we rely simply on cpu_online_mask to sync with
+ * arch-specific stop code without bloating the code with an
+ * additional atomic_t ad-hoc counter.
+ *
+ * As a consequence we'll need proper explicit memory barriers
+ * in case the other CPUs running the arch-specific stop-code
+ * would need to commit to memory some data (like saved_regs).
+ */
+ timeout = USEC_PER_SEC;
+ while (num_online_cpus() > this_cpu_online && timeout--)
+ udelay(1);
+ /* ensure any stopping-CPUs memory access is made visible */
+ smp_rmb();
+ if (num_online_cpus() > this_cpu_online)
+ pr_warn("failed to stop secondary CPUs %*pbl\n",
+ cpumask_pr_args(cpu_online_mask));
+ }
+ /* Perform final (possibly arch-specific) work on this CPU */
+ arch_smp_cpus_stop_complete();
+}
+#endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-08-23 11:52 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Zijlstra, Catalin Marinas, linux-kernel, linux-mm,
Dan Williams, linux-arm-kernel
In-Reply-To: <20190823113715.n3lc73vtc4ea2ln4@willie-the-truck>
On Fri, 2019-08-23 at 12:37 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 05:33:23PM -0400, Qian Cai wrote:
> > https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
> >
> > Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> > CONFIG_PROVE_LOCKING=y results in hanging.
>
> Hmm, but the config you link to above has:
>
> # CONFIG_PROVE_LOCKING is not set
>
> so I'm confused. Also, which tree is this?
I manually turn on CONFIG_PROVE_LOCKING=y on the top of that, and reproduce on
both the mainline and linux-next trees.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: orange-pi-3: Enable WiFi
From: Maxime Ripard @ 2019-08-23 11:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Ondřej Jirman, Mark Rutland, devicetree, linux-kernel,
Rob Herring, linux-arm-kernel
In-Reply-To: <CAGb2v65mDt8t2sceTzKvYP6XVHJgikXyYMc+xWxZFkTJ+LZ1fg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3546 bytes --]
On Fri, Aug 23, 2019 at 06:10:30PM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 23, 2019 at 6:08 PM Maxime Ripard <mripard@kernel.org> wrote:
> >
> > Hi,
> >
> > On Fri, Aug 23, 2019 at 11:42:28AM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Orange Pi 3 has AP6256 WiFi/BT module. WiFi part of the module is called
> > > bcm43356 and can be used with the brcmfmac driver. The module is powered by
> > > the two always on regulators (not AXP805).
> > >
> > > WiFi uses a PG port with 1.8V voltage level signals. SoC needs to be
> > > configured so that it sets up an 1.8V input bias on this port. This is done
> > > by the pio driver by reading the vcc-pg-supply voltage.
> > >
> > > You'll need a fw_bcm43456c5_ag.bin firmware file and nvram.txt
> > > configuration that can be found in the Xulongs's repository for H6:
> > >
> > > https://github.com/orangepi-xunlong/OrangePiH6_external/tree/master/ap6256
> > >
> > > Mainline brcmfmac driver expects the firmware and nvram at the following
> > > paths relative to the firmware directory:
> > >
> > > brcm/brcmfmac43456-sdio.bin
> > > brcm/brcmfmac43456-sdio.txt
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > ---
> > >
> > > Since RTC patches for H6 were merged, this can now go in too, if it looks ok.
> > >
> > > Other patches for this WiFi chip support were merged in previous cycles,
> > > so this just needs enabling in DTS now.
> > >
> > > Sorry for the links in the commit log, but this information is useful,
> > > even if the link itself goes bad. Any pointer what to google for
> > > (file names, tree name) is great for anyone searching in the future.
> >
> > I understand, but this should (also?) be in the wiki. Please add it
> > there too.
> >
> > > Please take a look.
> > >
> > > Thank you,
> > > Ondrej
> > >
> > > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 48 +++++++++++++++++++
> > > 1 file changed, 48 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > index eda9d5f640b9..49d954369087 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > @@ -56,6 +56,34 @@
> > > regulator-max-microvolt = <5000000>;
> > > regulator-always-on;
> > > };
> > > +
> > > + reg_vcc33_wifi: vcc33-wifi {
> > > + /* Always on 3.3V regulator for WiFi and BT */
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc33-wifi";
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-always-on;
> > > + vin-supply = <®_vcc5v>;
> > > + };
> > > +
> > > + reg_vcc_wifi_io: vcc-wifi-io {
> > > + /* Always on 1.8V/300mA regulator for WiFi and BT IO */
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc-wifi-io";
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-always-on;
> > > + vin-supply = <®_vcc33_wifi>;
> > > + };
> > > +
> > > + wifi_pwrseq: wifi_pwrseq {
>
> IIRC we shouldn't use underscores in node names. Maxime can you fix that up?
Done, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Zenghui Yu @ 2019-08-23 11:45 UTC (permalink / raw)
To: Steven Price, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: kvm, linux-doc, Catalin Marinas, Russell King, linux-kernel,
Paolo Bonzini
In-Reply-To: <20190821153656.33429-11-steven.price@arm.com>
Hi Steven,
On 2019/8/21 23:36, Steven Price wrote:
> Enable paravirtualization features when running under a hypervisor
> supporting the PV_TIME_ST hypercall.
>
> For each (v)CPU, we ask the hypervisor for the location of a shared
> page which the hypervisor will use to report stolen time to us. We set
> pv_time_ops to the stolen time function which simply reads the stolen
> value from the shared page for a VCPU. We guarantee single-copy
> atomicity using READ_ONCE which means we can also read the stolen
> time for another VCPU than the currently running one while it is
> potentially being updated by the hypervisor.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/paravirt.h | 9 +-
> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
> arch/arm64/kernel/time.c | 3 +
> include/linux/cpuhotplug.h | 1 +
> 4 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
> index 799d9dd6f7cc..125c26c42902 100644
> --- a/arch/arm64/include/asm/paravirt.h
> +++ b/arch/arm64/include/asm/paravirt.h
> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
> {
> return pv_ops.time.steal_clock(cpu);
> }
> -#endif
> +
> +int __init kvm_guest_init(void);
> +
> +#else
> +
> +#define kvm_guest_init()
> +
> +#endif // CONFIG_PARAVIRT
>
> #endif
> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
> index 4cfed91fe256..ea8dbbbd3293 100644
> --- a/arch/arm64/kernel/paravirt.c
> +++ b/arch/arm64/kernel/paravirt.c
> @@ -6,13 +6,161 @@
> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> */
>
> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cpuhotplug.h>
> #include <linux/export.h>
> +#include <linux/io.h>
> #include <linux/jump_label.h>
> +#include <linux/printk.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/slab.h>
> #include <linux/types.h>
> +
> #include <asm/paravirt.h>
> +#include <asm/pvclock-abi.h>
> +#include <asm/smp_plat.h>
>
> struct static_key paravirt_steal_enabled;
> struct static_key paravirt_steal_rq_enabled;
>
> struct paravirt_patch_template pv_ops;
> EXPORT_SYMBOL_GPL(pv_ops);
> +
> +struct kvmarm_stolen_time_region {
> + struct pvclock_vcpu_stolen_time *kaddr;
> +};
> +
> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
> +
> +static bool steal_acc = true;
> +static int __init parse_no_stealacc(char *arg)
> +{
> + steal_acc = false;
> + return 0;
> +}
> +
> +early_param("no-steal-acc", parse_no_stealacc);
> +
> +/* return stolen time in ns by asking the hypervisor */
> +static u64 kvm_steal_clock(int cpu)
> +{
> + struct kvmarm_stolen_time_region *reg;
> +
> + reg = per_cpu_ptr(&stolen_time_region, cpu);
> + if (!reg->kaddr) {
> + pr_warn_once("stolen time enabled but not configured for cpu %d\n",
> + cpu);
> + return 0;
> + }
> +
> + return le64_to_cpu(READ_ONCE(reg->kaddr->stolen_time));
> +}
> +
> +static int disable_stolen_time_current_cpu(void)
> +{
> + struct kvmarm_stolen_time_region *reg;
> +
> + reg = this_cpu_ptr(&stolen_time_region);
> + if (!reg->kaddr)
> + return 0;
> +
> + memunmap(reg->kaddr);
> + memset(reg, 0, sizeof(*reg));
> +
> + return 0;
> +}
> +
> +static int stolen_time_dying_cpu(unsigned int cpu)
> +{
> + return disable_stolen_time_current_cpu();
> +}
> +
> +static int init_stolen_time_cpu(unsigned int cpu)
> +{
> + struct kvmarm_stolen_time_region *reg;
> + struct arm_smccc_res res;
> +
> + reg = this_cpu_ptr(&stolen_time_region);
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_TIME_ST, &res);
> +
> + if ((long)res.a0 < 0)
> + return -EINVAL;
> +
> + reg->kaddr = memremap(res.a0,
> + sizeof(struct pvclock_vcpu_stolen_time),
> + MEMREMAP_WB);
cpuhp callbacks can be invoked in atomic context (see:
secondary_start_kernel ->
notify_cpu_starting ->
invoke callbacks),
but memremap might sleep...
Try to run a DEBUG_ATOMIC_SLEEP enabled PV guest, I guess we will be
greeted by the Sleep-in-Atomic-Context BUG. We need an alternative
here?
> +
> + if (!reg->kaddr) {
> + pr_warn("Failed to map stolen time data structure\n");
> + return -ENOMEM;
> + }
> +
> + if (le32_to_cpu(reg->kaddr->revision) != 0 ||
> + le32_to_cpu(reg->kaddr->attributes) != 0) {
> + pr_warn("Unexpected revision or attributes in stolen time data\n");
> + return -ENXIO;
> + }
> +
> + return 0;
> +}
> +
> +static int kvm_arm_init_stolen_time(void)
> +{
> + int ret;
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARM_KVMPV_STARTING,
> + "hypervisor/kvmarm/pv:starting",
> + init_stolen_time_cpu, stolen_time_dying_cpu);
> + if (ret < 0)
> + return ret;
> + return 0;
> +}
> +
> +static bool has_kvm_steal_clock(void)
> +{
> + struct arm_smccc_res res;
> +
> + /* To detect the presence of PV time support we require SMCCC 1.1+ */
> + if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> + return false;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_HV_PV_FEATURES, &res);
> +
> + if (res.a0 != SMCCC_RET_SUCCESS)
> + return false;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_HV_PV_FEATURES,
> + ARM_SMCCC_HV_PV_TIME_ST, &res);
> +
> + if (res.a0 != SMCCC_RET_SUCCESS)
> + return false;
> +
> + return true;
> +}
> +
> +int __init kvm_guest_init(void)
> +{
> + int ret = 0;
And this look like a redundant initialization?
Thanks,
zenghui
> +
> + if (!has_kvm_steal_clock())
> + return 0;
> +
> + ret = kvm_arm_init_stolen_time();
> + if (ret)
> + return ret;
> +
> + pv_ops.time.steal_clock = kvm_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + if (steal_acc)
> + static_key_slow_inc(¶virt_steal_rq_enabled);
> +
> + pr_info("using stolen time PV\n");
> +
> + return 0;
> +}
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index 0b2946414dc9..a52aea14c6ec 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -30,6 +30,7 @@
>
> #include <asm/thread_info.h>
> #include <asm/stacktrace.h>
> +#include <asm/paravirt.h>
>
> unsigned long profile_pc(struct pt_regs *regs)
> {
> @@ -65,4 +66,6 @@ void __init time_init(void)
>
> /* Calibrate the delay loop directly */
> lpj_fine = arch_timer_rate / HZ;
> +
> + kvm_guest_init();
> }
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 068793a619ca..89d75edb5750 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -136,6 +136,7 @@ enum cpuhp_state {
> /* Must be the last timer callback */
> CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_ARM_XEN_STARTING,
> + CPUHP_AP_ARM_KVMPV_STARTING,
> CPUHP_AP_ARM_CORESIGHT_STARTING,
> CPUHP_AP_ARM64_ISNDEP_STARTING,
> CPUHP_AP_SMPCFD_DYING,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Leonard Crestez @ 2019-08-23 11:47 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, Krzysztof Kozlowski,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <c03f5a54-4c7c-f574-55ba-d84b6b160a06@samsung.com>
On 23.08.2019 11:36, Chanwoo Choi wrote:
> On 19. 8. 22. 오후 9:24, Leonard Crestez wrote:
>> On 22.08.2019 14:06, Chanwoo Choi wrote:
>>> On 19. 8. 22. 오후 7:58, Leonard Crestez wrote:
>>>> On 8/22/2019 1:03 PM, Chanwoo Choi wrote:
>>>>> This patch doesn't check the range of input value
>>>>> with the supported frequencies of devfreq device.
>>>>>
>>>>> For example,
>>>>> The devfreq0 device has the following available frequencies
>>>>> 100000000 200000000 300000000
>>>>>
>>>>> and then user enters the 500000000 as following:
>>>>> echo 500000000 > /sys/class/devfreq/devfreq0/min_freq
>>>>>
>>>>> In result, get_effective_min_freq() will return the 500000000.
>>>>> It is wrong value. it show the unsupported frequency through
>>>>> min_freq sysfs path.
>>>>
>>>> Through dev_pm_qos devices can also ask for a freq higher than the
>>>> maximum OPP and unlike sysfs there is no way to reject such requests,
>>>> instead PM qos claims it's based on "best effort".
>>>>
>>>> There are many requests in the kernel for "PM_QOS_CPU_DMA_LATENCY 0" and
>>>> I think that DEV_PM_QOS_MIN_FREQUENCY, MAX_S32 is a reasonable way for a
>>>> device to request "max performance" from devfreq.
>>>>
>>>> Rejecting min > max is complicated (what happens to rejected requests
>>>> when max goes back up?) and I think it's better to just stick with a
>>>> "max overrides min" policy since it can already deal with conflicts.
>>>>
>>>> Do you have a usecase for rejecting out-of-range min_freq from
>>>> userspace? cpufreq also accepts arbitrary min/max values and handles them.
>>>
>>> I don't mean the rejecting when user enter the out-of-range frequency.
>>> As I commented, user can enter the value they want. But, we should
>>> check the range of input because devfreq have to show the correct supported
>>> frequency through sysfs.
>>
>> We can avoid showing an out-of-range value in min_freq by printing
>> min(min_freq, max_freq).
>
> You can check the range of frequency in the get_min_freq()/get_max_freq().
> I want to return the meaningful frequency from get_min_freq()/get_max_freq().
>
> Everyone expects get_min_freq()/get_max_freq() functions will retunrn
> the supported min/max frequency. If get_min_freq()/get_max_freq()
> return the our-of-range frequency, it is not nice and cause the confusion
> why these functions return the out-of-range frequency..
>
> Also, if we don't check the return value of dev_pm_qos_read_value(),
> the out-of-range frequency of dev_pm_qos_read_value() would be used
> on multiple point of devfreq.c. I think that it is not good.
OK, I will try to partially move the min/max conflict logic from
"update_devfreq" to a "get_freq_range" function and call that from
show_min_freq/show_max_freq.
>> The max_freq value from pm_qos can still be between OPPs so maybe print
>> devfreq_recommended_opp(max_freq, DEVFREQ_FLAG_LEAST_UPPER_BOUND).
>>
>>>> In theory pm_qos could be extended to differentiate between "soft"
>>>> requests (current behavior) and "hard" requests which return errors if
>>>> they can't be guaranteed but this is far out of scope.
>>>
>>> I think that you agreed the limitation of dev_pm_qos when entering
>>> or requesting the unsupported frequency.
>>
>> Yes, "best effort qos" is acceptable for now.
>
> And please don't remove the my previous comment.
> Just reply your opinion without any removal.
Sorry, when responding I usually trim sections which are very old or
where there appears to be broad agreement.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
From: Matthias Brugger @ 2019-08-23 11:43 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <29eb73c1-04f4-deec-3136-f22434e0e541@gmail.com>
On 23/08/2019 13:36, Matthias Brugger wrote:
>
>
> On 20/08/2019 10:49, Bibby Hsieh wrote:
>> GCE hardware stored event information in own internal sysram,
>> if the initial value in those sysram is not zero value
>> it will cause a situation that gce can wait the event immediately
>> after client ask gce to wait event but not really trigger the
>> corresponding hardware.
>>
>> In order to make sure that the wait event function is
>> exactly correct, we need to clear the sysram value in
>> cmdq initial flow.
>>
>> Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
>>
>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
I oversaw some things/nits.
Patch subject should be:
mailbox: mediatek: cmdq: clear the event in cmdq initial flow
>> ---
>> drivers/mailbox/mtk-cmdq-mailbox.c | 5 +++++
>> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
>> include/linux/soc/mediatek/mtk-cmdq.h | 3 ---
>> 3 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
>> index 69daaadc3a5f..9a6ce9f5a7db 100644
>> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
>> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
>> @@ -21,6 +21,7 @@
>> #define CMDQ_NUM_CMD(t) (t->cmd_buf_size / CMDQ_INST_SIZE)
>>
>> #define CMDQ_CURR_IRQ_STATUS 0x10
>> +#define CMDQ_SYNC_TOKEN_UPDATE 0x68
>> #define CMDQ_THR_SLOT_CYCLES 0x30
>> #define CMDQ_THR_BASE 0x100
>> #define CMDQ_THR_SIZE 0x80
>> @@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
>>
>> static void cmdq_init(struct cmdq *cmdq)
>> {
>> + int i;
>> +
>> WARN_ON(clk_enable(cmdq->clock) < 0);
>> writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
>> + for (i = 0; i <= CMDQ_MAX_EVENT; i++)
>> + writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
I think CMDQ_SYNC_TOKEN_UPDATE is not a good name for the define.
Any reason why we couldn't name it something like CMDQ_SYNC_TOKEN_RESET?
>> clk_disable(cmdq->clock);
>> }
>>
>> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
>> index ccb73422c2fa..911475da7a53 100644
>> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
>> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
>> @@ -19,6 +19,8 @@
>> #define CMDQ_WFE_UPDATE BIT(31)
>> #define CMDQ_WFE_WAIT BIT(15)
>> #define CMDQ_WFE_WAIT_VALUE 0x1
>> +/** cmdq event maximum */
While at it, add a new line before the comment.
Regards,
Matthias
>> +#define CMDQ_MAX_EVENT 0x3ff
>>
>> /*
>> * CMDQ_CODE_MASK:
>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>> index 54ade13a9b15..4e8899972db4 100644
>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>> @@ -13,9 +13,6 @@
>>
>> #define CMDQ_NO_TIMEOUT 0xffffffffu
>>
>> -/** cmdq event maximum */
>> -#define CMDQ_MAX_EVENT 0x3ff
>> -
>> struct cmdq_pkt;
>>
>> struct cmdq_client {
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Will Deacon @ 2019-08-23 11:37 UTC (permalink / raw)
To: Qian Cai
Cc: Peter Zijlstra, Catalin Marinas, linux-kernel, linux-mm,
Dan Williams, linux-arm-kernel
In-Reply-To: <1566509603.5576.10.camel@lca.pw>
On Thu, Aug 22, 2019 at 05:33:23PM -0400, Qian Cai wrote:
> https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
>
> Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> CONFIG_PROVE_LOCKING=y results in hanging.
Hmm, but the config you link to above has:
# CONFIG_PROVE_LOCKING is not set
so I'm confused. Also, which tree is this?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
From: Matthias Brugger @ 2019-08-23 11:36 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820084932.22282-7-bibby.hsieh@mediatek.com>
On 20/08/2019 10:49, Bibby Hsieh wrote:
> GCE hardware stored event information in own internal sysram,
> if the initial value in those sysram is not zero value
> it will cause a situation that gce can wait the event immediately
> after client ask gce to wait event but not really trigger the
> corresponding hardware.
>
> In order to make sure that the wait event function is
> exactly correct, we need to clear the sysram value in
> cmdq initial flow.
>
> Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 5 +++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
> include/linux/soc/mediatek/mtk-cmdq.h | 3 ---
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 69daaadc3a5f..9a6ce9f5a7db 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -21,6 +21,7 @@
> #define CMDQ_NUM_CMD(t) (t->cmd_buf_size / CMDQ_INST_SIZE)
>
> #define CMDQ_CURR_IRQ_STATUS 0x10
> +#define CMDQ_SYNC_TOKEN_UPDATE 0x68
> #define CMDQ_THR_SLOT_CYCLES 0x30
> #define CMDQ_THR_BASE 0x100
> #define CMDQ_THR_SIZE 0x80
> @@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
>
> static void cmdq_init(struct cmdq *cmdq)
> {
> + int i;
> +
> WARN_ON(clk_enable(cmdq->clock) < 0);
> writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
> + for (i = 0; i <= CMDQ_MAX_EVENT; i++)
> + writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
> clk_disable(cmdq->clock);
> }
>
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index ccb73422c2fa..911475da7a53 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -19,6 +19,8 @@
> #define CMDQ_WFE_UPDATE BIT(31)
> #define CMDQ_WFE_WAIT BIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
> +/** cmdq event maximum */
> +#define CMDQ_MAX_EVENT 0x3ff
>
> /*
> * CMDQ_CODE_MASK:
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> index 54ade13a9b15..4e8899972db4 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -13,9 +13,6 @@
>
> #define CMDQ_NO_TIMEOUT 0xffffffffu
>
> -/** cmdq event maximum */
> -#define CMDQ_MAX_EVENT 0x3ff
> -
> struct cmdq_pkt;
>
> struct cmdq_client {
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND, PATCH v13 04/12] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
From: Matthias Brugger @ 2019-08-23 11:32 UTC (permalink / raw)
To: Bibby Hsieh, Jassi Brar, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, linux-arm-kernel, ginny.chen
In-Reply-To: <20190820084932.22282-5-bibby.hsieh@mediatek.com>
On 20/08/2019 10:49, Bibby Hsieh wrote:
> The interrupt mask and thread number has positive correlation,
> so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
> it by thread number.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 00d5219094e5..8fddd26288e8 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -18,7 +18,6 @@
> #include <linux/of_device.h>
>
> #define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
> -#define CMDQ_IRQ_MASK 0xffff
> #define CMDQ_NUM_CMD(t) (t->cmd_buf_size / CMDQ_INST_SIZE)
>
> #define CMDQ_CURR_IRQ_STATUS 0x10
> @@ -72,6 +71,7 @@ struct cmdq {
> void __iomem *base;
> u32 irq;
> u32 thread_nr;
> + u32 irq_mask;
> struct cmdq_thread *thread;
> struct clk *clock;
> bool suspended;
> @@ -285,11 +285,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
> unsigned long irq_status, flags = 0L;
> int bit;
>
> - irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
> - if (!(irq_status ^ CMDQ_IRQ_MASK))
> + irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
> + if (!(irq_status ^ cmdq->irq_mask))
> return IRQ_NONE;
>
> - for_each_clear_bit(bit, &irq_status, fls(CMDQ_IRQ_MASK)) {
> + for_each_clear_bit(bit, &irq_status, cmdq->thread_nr) {
> struct cmdq_thread *thread = &cmdq->thread[bit];
>
> spin_lock_irqsave(&thread->chan->lock, flags);
> @@ -473,6 +473,9 @@ static int cmdq_probe(struct platform_device *pdev)
> dev_err(dev, "failed to get irq\n");
> return -EINVAL;
> }
> +
> + cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
> + cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
> err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
> "mtk_cmdq", cmdq);
> if (err < 0) {
> @@ -489,7 +492,6 @@ static int cmdq_probe(struct platform_device *pdev)
> return PTR_ERR(cmdq->clock);
> }
>
> - cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
> cmdq->mbox.dev = dev;
> cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
> sizeof(*cmdq->mbox.chans), GFP_KERNEL);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-23 11:27 UTC (permalink / raw)
To: Philipp Zabel, Suman Anna, Keerthy, ssantosh, linux-arm-kernel,
linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1566550205.3023.4.camel@pengutronix.de>
On 23.8.2019 11.50, Philipp Zabel wrote:
> On Wed, 2019-08-21 at 21:15 +0300, Tero Kristo wrote:
>> On 21.8.2019 18.45, Suman Anna wrote:
>>> On 8/21/19 10:10 AM, Philipp Zabel wrote:
> [...]
>>>> In general, assuming the device tree contains no errors, this should not
>>>> matter much, but I think it is nice if the reset driver, even with a
>>>> misconfigured device tree, can't write into arbitrary bit fields.
>>>
>>> Tero,
>>> Can you add a check for this if possible?
>>
>> Well, I can enforce the usage of reset bit mapping, which I have already
>> implemented for some SoCs like am33xx. If the specific ID is not found,
>> I can bail out. So, basically in this example requesting reset at index
>> 3 would succeed, but it would fail for any other ID; this would be
>> direct HW bit mapping.
>
> That should be fine.
Ok, I am re-working it like this locally right now.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 11:17 UTC (permalink / raw)
To: Will Deacon, tglx
Cc: linux-arch, shuah, daniel.lezcano, catalin.marinas, arnd, salyzyn,
huw, andre.przywara, Chris Clayton, will.deacon, linux-mips, ralf,
LKML, paul.burton, linux-kselftest, linux, sthotton, 0x7f454c46,
vincenzo.frascino, pcc, linux-arm-kernel
In-Reply-To: <20190823104050.o6golaa4fmdd7np5@willie-the-truck>
On Fri, Aug 23, 2019 at 11:40:50AM +0100, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 11:36:54AM +0100, Russell King - ARM Linux admin wrote:
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge the patches for 32-bit
> > ARM, which I don't want to do if doing so will cause this regression on
> > 32-bit ARM as well.
>
> tglx fixed it:
>
> https://lkml.kernel.org/r/alpine.DEB.2.21.1908221257580.1983@nanos.tec.linutronix.de
>
> which I assume is getting routed as a fix via -tip.
Right, so Chris reported the issue to everyone involved. Tglx's
reply severely trimmed the Cc list so folk like me had no idea what
was going on, removing even the mailing lists. On the face of it,
it looks like an intentional attempt to cut people out of the loop
who really should've been kept in the loop. Yea, that's just great.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/mediatek: fix implicit function declaration
From: Anders Roxell @ 2019-08-23 11:07 UTC (permalink / raw)
To: ck.hu, p.zabel, airlied, daniel, matthias.bgg
Cc: Anders Roxell, linux-mediatek, linux-arm-kernel, dri-devel,
linux-kernel
When building mtk_drm_drv.o the following build error is seen:
../drivers/gpu/drm/mediatek/mtk_drm_drv.c: In function ‘mtk_drm_kms_init’:
../drivers/gpu/drm/mediatek/mtk_drm_drv.c:291:8: error: implicit declaration of
function ‘dma_set_max_seg_size’; did you mean ‘drm_rect_adjust_size’? [-Werror=implicit-function-declaration]
ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
^~~~~~~~~~~~~~~~~~~~
drm_rect_adjust_size
../drivers/gpu/drm/mediatek/mtk_drm_drv.c:291:52: error: implicit declaration of
function ‘DMA_BIT_MASK’; did you mean ‘BIT_MASK’? [-Werror=implicit-function-declaration]
ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
^~~~~~~~~~~~
BIT_MASK
Rework to add a missing include file 'linux/dma-mapping.h', because that
is the (only) header file containing that declaration.
Fixes: 070955558e82 ("drm/mediatek: set DMA max segment size")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 54536176bcbb..352b81a7a670 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -10,6 +10,7 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
+#include <linux/dma-mapping.h>
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Regression in 5.3-rc1 and later
From: Russell King - ARM Linux admin @ 2019-08-23 10:51 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, daniel.lezcano, linux-mips, linux-kselftest, arnd,
huw, andre.przywara, Chris Clayton, will.deacon, LKML, ralf,
salyzyn, paul.burton, linux, 0x7f454c46, catalin.marinas, pcc,
tglx, sthotton, shuah, linux-arm-kernel
In-Reply-To: <8ab59d01-348e-9ac1-2944-5e98acd9b1f8@arm.com>
On Fri, Aug 23, 2019 at 11:43:32AM +0100, Vincenzo Frascino wrote:
> Hi Russell,
>
> On 8/23/19 11:36 AM, Russell King - ARM Linux admin wrote:
> > Hi,
> >
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge the patches for 32-bit
> > ARM, which I don't want to do if doing so will cause this regression on
> > 32-bit ARM as well.
> >
>
> The regression is sorted as of yesterday, a new patch is going through tip:
> timers/urgent and will be part of the next -rc.
>
> If you want to merge them there should be nothing blocking.
I don't have access to the tip tree.
I'll wait a kernel release cycle instead.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-23 10:50 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
james.morse, Gregory CLEMENT, bp, mchehab, linux-arm-kernel,
patches
In-Reply-To: <20190823104621.GY13294@shell.armlinux.org.uk>
On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > From: Jan Luebbe <jlu@pengutronix.de>
> >
> > The macro name is too generic, so add a AURORA_ prefix.
> >
> > Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > ---
> > arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
>
> I can't apply this series - this file does not exist in my tree, and
> from what git tells me, it never has existed. Maybe it's in someone
> elses tree?
I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
which is where it has been since it was originally submitted in 2012.
>
> > arch/arm/mm/cache-l2x0.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > index c86124769831..dc5c479ec4c3 100644
> > --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > @@ -41,7 +41,7 @@
> > #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> > (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
> >
> > -#define MAX_RANGE_SIZE 1024
> > +#define AURORA_MAX_RANGE_SIZE 1024
> >
> > #define AURORA_WAY_SIZE_SHIFT 2
> >
> > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > index 428d08718107..83b733a1f1e6 100644
> > --- a/arch/arm/mm/cache-l2x0.c
> > +++ b/arch/arm/mm/cache-l2x0.c
> > @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> > * since cache range operations stall the CPU pipeline
> > * until completion.
> > */
> > - if (end > start + MAX_RANGE_SIZE)
> > - end = start + MAX_RANGE_SIZE;
> > + if (end > start + AURORA_MAX_RANGE_SIZE)
> > + end = start + AURORA_MAX_RANGE_SIZE;
> >
> > /*
> > * Cache range operations can't straddle a page boundary.
> > --
> > 2.22.0
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-23 10:46 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland, devicetree, jlu, linux-edac, linux-kernel, robh+dt,
james.morse, Gregory CLEMENT, bp, mchehab, linux-arm-kernel,
patches
In-Reply-To: <20190712034904.5747-2-chris.packham@alliedtelesis.co.nz>
On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> From: Jan Luebbe <jlu@pengutronix.de>
>
> The macro name is too generic, so add a AURORA_ prefix.
>
> Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
I can't apply this series - this file does not exist in my tree, and
from what git tells me, it never has existed. Maybe it's in someone
elses tree?
> arch/arm/mm/cache-l2x0.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> index c86124769831..dc5c479ec4c3 100644
> --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> @@ -41,7 +41,7 @@
> #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
>
> -#define MAX_RANGE_SIZE 1024
> +#define AURORA_MAX_RANGE_SIZE 1024
>
> #define AURORA_WAY_SIZE_SHIFT 2
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 428d08718107..83b733a1f1e6 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1352,8 +1352,8 @@ static unsigned long aurora_range_end(unsigned long start, unsigned long end)
> * since cache range operations stall the CPU pipeline
> * until completion.
> */
> - if (end > start + MAX_RANGE_SIZE)
> - end = start + MAX_RANGE_SIZE;
> + if (end > start + AURORA_MAX_RANGE_SIZE)
> + end = start + AURORA_MAX_RANGE_SIZE;
>
> /*
> * Cache range operations can't straddle a page boundary.
> --
> 2.22.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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