[PATCH 4.1 012/123] MIPS: Fix erroneous JR emulation for MIPS R6

[PATCH 4.1 012/123] MIPS: Fix erroneous JR emulation for MIPS R6

[Greg Kroah-Hartman]

4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Markos Chandras <markos.chandras@imgtec.com>

commit 143fefc8f315cd10e046e6860913c421c3385cb1 upstream.

Commit 5f9f41c474befb4ebbc40b27f65bb7d649241581 ("MIPS: kernel: Prepare
the JR instruction for emulation on MIPS R6") added support for
emulating the JR instruction on MIPS R6 cores but that introduced a bug
which could be triggered when hitting a JALR opcode because the code used
the wrong field in the 'r_format' struct to determine the instruction
opcode. This lead to crashes because an emulated JALR instruction was
treated as a JR one when the R6 emulator was turned off.

Fixes: 5f9f41c474be ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6")
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10583/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/math-emu/cp1emu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/math-emu/cp1emu.c
+++ b/arch/mips/math-emu/cp1emu.c
@@ -451,7 +451,7 @@ static int isBranchInstr(struct pt_regs
 			/* Fall through */
 		case jr_op:
 			/* For R6, JR already emulated in jalr_op */
-			if (NO_R6EMU && insn.r_format.opcode == jr_op)
+			if (NO_R6EMU && insn.r_format.func == jr_op)
 				break;
 			*contpc = regs->regs[insn.r_format.rs];
 			return 1;

[PATCH 4.1 013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Greg Kroah-Hartman]

4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Markos Chandras <markos.chandras@imgtec.com>

commit cccf34e9411c41b0cbfb41980fe55fc8e7c98fd2 upstream.

MT_SMP is not the only SMP option for MT cores. The MT_SMP option
allows more than one VPE per core to appear as a secondary CPU in the
system. Because of how CM works, it propagates the address-based
cache ops to the secondary cores but not the index-based ones.
Because of that, the code does not use IPIs to flush the L1 caches on
secondary cores because the CM would have done that already. However,
the CM functionality is independent of the type of SMP kernel so even in
non-MT kernels, IPIs are not necessary. As a result of which, we change
the conditional to depend on the CM presence. Moreover, since VPEs on
the same core share the same L1 caches, there is no need to send an
IPI on all of them so we calculate a suitable cpumask with only one
VPE per core.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10654/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/include/asm/smp.h |    1 +
 arch/mips/kernel/smp.c      |   44 +++++++++++++++++++++++++++++++++++++++++++-
 arch/mips/mm/c-r4k.c        |   14 +++++++++++---
 3 files changed, 55 insertions(+), 4 deletions(-)

--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -23,6 +23,7 @@
 extern int smp_num_siblings;
 extern cpumask_t cpu_sibling_map[];
 extern cpumask_t cpu_core_map[];
+extern cpumask_t cpu_foreign_map;
 
 #define raw_smp_processor_id() (current_thread_info()->cpu)
 
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -63,6 +63,13 @@ EXPORT_SYMBOL(cpu_sibling_map);
 cpumask_t cpu_core_map[NR_CPUS] __read_mostly;
 EXPORT_SYMBOL(cpu_core_map);
 
+/*
+ * A logcal cpu mask containing only one VPE per core to
+ * reduce the number of IPIs on large MT systems.
+ */
+cpumask_t cpu_foreign_map __read_mostly;
+EXPORT_SYMBOL(cpu_foreign_map);
+
 /* representing cpus for which sibling maps can be computed */
 static cpumask_t cpu_sibling_setup_map;
 
@@ -103,6 +110,29 @@ static inline void set_cpu_core_map(int
 	}
 }
 
+/*
+ * Calculate a new cpu_foreign_map mask whenever a
+ * new cpu appears or disappears.
+ */
+static inline void calculate_cpu_foreign_map(void)
+{
+	int i, k, core_present;
+	cpumask_t temp_foreign_map;
+
+	/* Re-calculate the mask */
+	for_each_online_cpu(i) {
+		core_present = 0;
+		for_each_cpu(k, &temp_foreign_map)
+			if (cpu_data[i].package == cpu_data[k].package &&
+			    cpu_data[i].core == cpu_data[k].core)
+				core_present = 1;
+		if (!core_present)
+			cpumask_set_cpu(i, &temp_foreign_map);
+	}
+
+	cpumask_copy(&cpu_foreign_map, &temp_foreign_map);
+}
+
 struct plat_smp_ops *mp_ops;
 EXPORT_SYMBOL(mp_ops);
 
@@ -146,6 +176,8 @@ asmlinkage void start_secondary(void)
 	set_cpu_sibling_map(cpu);
 	set_cpu_core_map(cpu);
 
+	calculate_cpu_foreign_map();
+
 	cpumask_set_cpu(cpu, &cpu_callin_map);
 
 	synchronise_count_slave(cpu);
@@ -173,9 +205,18 @@ void __irq_entry smp_call_function_inter
 static void stop_this_cpu(void *dummy)
 {
 	/*
-	 * Remove this CPU:
+	 * Remove this CPU. Be a bit slow here and
+	 * set the bits for every online CPU so we don't miss
+	 * any IPI whilst taking this VPE down.
 	 */
+
+	cpumask_copy(&cpu_foreign_map, cpu_online_mask);
+
+	/* Make it visible to every other CPU */
+	smp_mb();
+
 	set_cpu_online(smp_processor_id(), false);
+	calculate_cpu_foreign_map();
 	local_irq_disable();
 	while (1);
 }
@@ -197,6 +238,7 @@ void __init smp_prepare_cpus(unsigned in
 	mp_ops->prepare_cpus(max_cpus);
 	set_cpu_sibling_map(0);
 	set_cpu_core_map(0);
+	calculate_cpu_foreign_map();
 #ifndef CONFIG_HOTPLUG_CPU
 	init_cpu_present(cpu_possible_mask);
 #endif
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -37,6 +37,7 @@
 #include <asm/cacheflush.h> /* for run_uncached() */
 #include <asm/traps.h>
 #include <asm/dma-coherence.h>
+#include <asm/mips-cm.h>
 
 /*
  * Special Variant of smp_call_function for use by cache functions:
@@ -51,9 +52,16 @@ static inline void r4k_on_each_cpu(void
 {
 	preempt_disable();
 
-#ifndef CONFIG_MIPS_MT_SMP
-	smp_call_function(func, info, 1);
-#endif
+	/*
+	 * The Coherent Manager propagates address-based cache ops to other
+	 * cores but not index-based ops. However, r4k_on_each_cpu is used
+	 * in both cases so there is no easy way to tell what kind of op is
+	 * executed to the other cores. The best we can probably do is
+	 * to restrict that call when a CM is not present because both
+	 * CM-based SMP protocols (CMP & CPS) restrict index-based cache ops.
+	 */
+	if (!mips_cm_present())
+		smp_call_function_many(&cpu_foreign_map, func, info, 1);
 	func(info);
 	preempt_enable();
 }

[PATCH 4.1 014/123] MIPS: Require O32 FP64 support for MIPS64 with O32 compat

[Greg Kroah-Hartman]

4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Paul Burton <paul.burton@imgtec.com>

commit 4e9d324d4288b082497c30bc55b8ad13acc7cf01 upstream.

MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with
support for MIPS32r6 binaries but without support for O32 with FP64 is
therefore a problem which can lead to incorrectly executed userland.

CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is
configured for MIPS32r6, but not when the kernel is configured for
MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in
such configurations to prevent building kernels which execute MIPS32r6
userland incorrectly.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Matthew Fortune <matthew.fortune@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10674/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1417,6 +1417,7 @@ config CPU_MIPS64_R6
 	select CPU_SUPPORTS_HIGHMEM
 	select CPU_SUPPORTS_MSA
 	select GENERIC_CSUM
+	select MIPS_O32_FP64_SUPPORT if MIPS32_O32
 	help
 	  Choose this option to build a kernel for release 6 or later of the
 	  MIPS64 architecture.  New MIPS processors, starting with the Warrior

[PATCH 4.1 015/123] MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU

[Greg Kroah-Hartman]

4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Markos Chandras <markos.chandras@imgtec.com>

commit fcc53b5f6c38acbf5d311ffc3e0da517491c6f7b upstream.

Commit 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6")
added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed
the 64-bit CPU case leading to FPU failures when requesting FR=1 mode
(which is always the case for MIPS R6 userland) when running a 32-bit
kernel on a 64-bit CPU. We also fix the MIPS R2 case.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Fixes: 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6")
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10734/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/include/asm/fpu.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/include/asm/fpu.h
+++ b/arch/mips/include/asm/fpu.h
@@ -74,7 +74,7 @@ static inline int __enable_fpu(enum fpu_
 		goto fr_common;
 
 	case FPU_64BIT:
-#if !(defined(CONFIG_CPU_MIPS32_R2) || defined(CONFIG_CPU_MIPS32_R6) \
+#if !(defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6) \
       || defined(CONFIG_64BIT))
 		/* we only have a 32-bit FPU */
 		return SIGFPE;

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote:
> 4.1-stable review patch.  If anyone has any objections, please let me know.
>
>
Yes, I have objection. Please look into excepts from my mail exchange 
with Markos:

> On 06/25/2015 03:59 AM, Markos Chandras wrote:
>
>> @@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info)
>>   {
>>   	preempt_disable();
>>   
>> -#ifndef CONFIG_MIPS_MT_SMP
>> -	smp_call_function(func, info, 1);
>> -#endif
>> +	if (config_enabled(CONFIG_SMP))
>> +		smp_call_function_many(&cpu_foreign_map, func, info, 1);
>>   	func(info);
>>   	preempt_enable();
>>   }
>
> You can NOT do this because r4k_on_each_cpu() is still used for 
> non-MIPS/IMG processors for SAFE INDEX cache flushes - 
> cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment).
>
>
> And a little explanation and history:
>
> The function r4k_on_each_cpu() can NOT be used simultaneously for 
> index cacheops and address cacheops because both have a different 
> rules in applying in other cores and that is different in inter-core 
> HW blocks of various vendors. CM propogates address cacheops from 
> core-to-core (no IPI calls are needed) but another vendors may do not 
> - this is indicated by CONFIG_MIPS_MT_SMP (and a dropped now 
> CONFIG_MIPS_MT_SMTC).
>
> Unfortunately, before 2.6.35.9 this function was used for index 
> cacheops too in any kernel and that is WRONG, at least for CM-based 
> systems.
> So, I splitted index and address cacheops and wrote a functions 
> r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 
> and it finally made a way to dev-linux-mti-3.6. This is a famous patch 
> named:
>
>     MIPS: Cache flush functions are reworked.
>
>     This patch is a preparation for EVA support in kernel.
>
>     However, it also fixes a bug then index cacheop was not ran
>     on multiple CPUs with unsafe index cacheops (flush_cache_vmap,
>     flush_icache_range, flush_cache_range, __flush_cache_all).
>
>     Additionally, it optimizes a usage of index and address cacheops for
>     address range flushes depending from address range size.
>
>     Because of that reasons it is a separate patch from EVA support.
>
>     Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>     Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
>     (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7)
>

(history is skipped)

Note: the replacement of

     if (config_enabled(CONFIG_SMP))

to
if (!mips_cm_present())

doesn't solve a problem - in CM-based environment the index cache ops 
MUST be delivered to other core via IPI.

- Leonid.

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote:
> 4.1-stable review patch.  If anyone has any objections, please let me know.
>
>
Yes, I have objection. Please look into excepts from my mail exchange 
with Markos:

> On 06/25/2015 03:59 AM, Markos Chandras wrote:
>
>> @@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info)
>>   {
>>   	preempt_disable();
>>   
>> -#ifndef CONFIG_MIPS_MT_SMP
>> -	smp_call_function(func, info, 1);
>> -#endif
>> +	if (config_enabled(CONFIG_SMP))
>> +		smp_call_function_many(&cpu_foreign_map, func, info, 1);
>>   	func(info);
>>   	preempt_enable();
>>   }
>
> You can NOT do this because r4k_on_each_cpu() is still used for 
> non-MIPS/IMG processors for SAFE INDEX cache flushes - 
> cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment).
>
>
> And a little explanation and history:
>
> The function r4k_on_each_cpu() can NOT be used simultaneously for 
> index cacheops and address cacheops because both have a different 
> rules in applying in other cores and that is different in inter-core 
> HW blocks of various vendors. CM propogates address cacheops from 
> core-to-core (no IPI calls are needed) but another vendors may do not 
> - this is indicated by CONFIG_MIPS_MT_SMP (and a dropped now 
> CONFIG_MIPS_MT_SMTC).
>
> Unfortunately, before 2.6.35.9 this function was used for index 
> cacheops too in any kernel and that is WRONG, at least for CM-based 
> systems.
> So, I splitted index and address cacheops and wrote a functions 
> r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 
> and it finally made a way to dev-linux-mti-3.6. This is a famous patch 
> named:
>
>     MIPS: Cache flush functions are reworked.
>
>     This patch is a preparation for EVA support in kernel.
>
>     However, it also fixes a bug then index cacheop was not ran
>     on multiple CPUs with unsafe index cacheops (flush_cache_vmap,
>     flush_icache_range, flush_cache_range, __flush_cache_all).
>
>     Additionally, it optimizes a usage of index and address cacheops for
>     address range flushes depending from address range size.
>
>     Because of that reasons it is a separate patch from EVA support.
>
>     Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>     Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
>     (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7)
>

(history is skipped)

Note: the replacement of

     if (config_enabled(CONFIG_SMP))

to
if (!mips_cm_present())

doesn't solve a problem - in CM-based environment the index cache ops 
MUST be delivered to other core via IPI.

- Leonid.

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[gregkh]

On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> On 08/08/2015 03:08 PM, gregkh@linuxfoundation.org wrote:
> >4.1-stable review patch.  If anyone has any objections, please let me know.
> >
> >
> Yes, I have objection. Please look into excepts from my mail exchange with
> Markos:
> 
> >On 06/25/2015 03:59 AM, Markos Chandras wrote:
> >
> >>@@ -51,9 +51,8 @@ static inline void r4k_on_each_cpu(void (*func) (void *info), void *info)
> >>  {
> >>  	preempt_disable();
> >>-#ifndef CONFIG_MIPS_MT_SMP
> >>-	smp_call_function(func, info, 1);
> >>-#endif
> >>+	if (config_enabled(CONFIG_SMP))
> >>+		smp_call_function_many(&cpu_foreign_map, func, info, 1);
> >>  	func(info);
> >>  	preempt_enable();
> >>  }
> >
> >You can NOT do this because r4k_on_each_cpu() is still used for
> >non-MIPS/IMG processors for SAFE INDEX cache flushes -
> >cpu_has_safe_index_cacheops (it is not safe in CM/CM2/CM3 environment).
> >
> >
> >And a little explanation and history:
> >
> >The function r4k_on_each_cpu() can NOT be used simultaneously for index
> >cacheops and address cacheops because both have a different rules in
> >applying in other cores and that is different in inter-core HW blocks of
> >various vendors. CM propogates address cacheops from core-to-core (no IPI
> >calls are needed) but another vendors may do not - this is indicated by
> >CONFIG_MIPS_MT_SMP (and a dropped now CONFIG_MIPS_MT_SMTC).
> >
> >Unfortunately, before 2.6.35.9 this function was used for index cacheops
> >too in any kernel and that is WRONG, at least for CM-based systems.
> >So, I splitted index and address cacheops and wrote a functions
> >r4k_indexop_on_each_cpu and put it in use in at least in dlm-2.6.35.9 and
> >it finally made a way to dev-linux-mti-3.6. This is a famous patch named:
> >
> >    MIPS: Cache flush functions are reworked.
> >
> >    This patch is a preparation for EVA support in kernel.
> >
> >    However, it also fixes a bug then index cacheop was not ran
> >    on multiple CPUs with unsafe index cacheops (flush_cache_vmap,
> >    flush_icache_range, flush_cache_range, __flush_cache_all).
> >
> >    Additionally, it optimizes a usage of index and address cacheops for
> >    address range flushes depending from address range size.
> >
> >    Because of that reasons it is a separate patch from EVA support.
> >
> >    Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
> >    Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
> >    (cherry picked from commit 6b05dd71da1136fbad0ce642790c4c99343f05e7)
> >
> 
> (history is skipped)
> 
> Note: the replacement of
> 
>     if (config_enabled(CONFIG_SMP))
> 
> to
> if (!mips_cm_present())
> 
> doesn't solve a problem - in CM-based environment the index cache ops MUST
> be delivered to other core via IPI.

So, this is broken in Linus's tree too?  Or is it fixed there, and if
so, what is the git commit id?

thanks,

greg k-h

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>
> So, this is broken in Linus's tree too?

Yes.

>    Or is it fixed there, and if
> so, what is the git commit id?

There is no an accepted fix. My old patch is in

https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12

It was a precursor for my EVA set of patches since2.6.35.9 but was never 
accepted and was lost during redesign of EVA by Markos.

- Leonid.

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>
> So, this is broken in Linus's tree too?

Yes.

>    Or is it fixed there, and if
> so, what is the git commit id?

There is no an accepted fix. My old patch is in

https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12

It was a precursor for my EVA set of patches since2.6.35.9 but was never 
accepted and was lost during redesign of EVA by Markos.

- Leonid.

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Markos Chandras]

On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> > On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> >>
> > So, this is broken in Linus's tree too?
> 
> Yes.
> 
> >    Or is it fixed there, and if
> > so, what is the git commit id?
> 
> There is no an accepted fix. My old patch is in
> 
> https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12
> 
> It was a precursor for my EVA set of patches since2.6.35.9 but was never 
> accepted and was lost during redesign of EVA by Markos.
> 
> - Leonid.
> 

I hope you realize that blocking this patch from the stable trees does not
actually fix the problem. The patch may not be perfect but it's better than what
we had before.

-- 
markos

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Markos Chandras]

On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> > On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> >>
> > So, this is broken in Linus's tree too?
> 
> Yes.
> 
> >    Or is it fixed there, and if
> > so, what is the git commit id?
> 
> There is no an accepted fix. My old patch is in
> 
> https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12
> 
> It was a precursor for my EVA set of patches since2.6.35.9 but was never 
> accepted and was lost during redesign of EVA by Markos.
> 
> - Leonid.
> 

I hope you realize that blocking this patch from the stable trees does not
actually fix the problem. The patch may not be perfect but it's better than what
we had before.

-- 
markos

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[gregkh]

On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
> >On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
> >>
> >So, this is broken in Linus's tree too?
> 
> Yes.

Great, as long as I am consistent, that's all that I care about :)

> >   Or is it fixed there, and if
> >so, what is the git commit id?
> 
> There is no an accepted fix. My old patch is in
> 
> https://git.linux-mips.org/cgit/yegoshin/mips.git/commit/?id=98f6c462eb5319a4dcb3830f902c48141f38cd12
> 
> It was a precursor for my EVA set of patches since2.6.35.9 but was never
> accepted and was lost during redesign of EVA by Markos.

Please work with the mips developers to get this accepted, and mark it
for -stable as well.

thanks,

greg k-h

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/10/2015 12:19 PM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
>> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
>>> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>> So, this is broken in Linus's tree too?
>> Yes.
> Great, as long as I am consistent, that's all that I care about :)
>
>

You asked "If anyone has any objections, please let me know" and I did that.

- Leonid.

Re: [4.1,013/123] MIPS: c-r4k: Fix cache flushing for MT cores

[Leonid Yegoshin]

On 08/10/2015 12:19 PM, gregkh@linuxfoundation.org wrote:
> On Mon, Aug 10, 2015 at 12:12:05PM -0700, Leonid Yegoshin wrote:
>> On 08/10/2015 11:49 AM, gregkh@linuxfoundation.org wrote:
>>> On Mon, Aug 10, 2015 at 11:36:34AM -0700, Leonid Yegoshin wrote:
>>> So, this is broken in Linus's tree too?
>> Yes.
> Great, as long as I am consistent, that's all that I care about :)
>
>

You asked "If anyone has any objections, please let me know" and I did that.

- Leonid.