It was discovered that some device have CBR address set to 0 causing
kernel panic when arch_sync_dma_for_cpu_all is called.

This was notice in situation where the system is booted from TP1 and
BMIPS_GET_CBR() returns 0 instead of a valid address and
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.

The current check whether RAC flush should be disabled or not are not
enough hence lets check if CBR is a valid address or not.

Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
 arch/mips/bmips/setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index ec180ab92eaa..66a8ba19c287 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -110,7 +110,8 @@ static void bcm6358_quirks(void)
 	 * RAC flush causes kernel panics on BCM6358 when booting from TP1
 	 * because the bootloader is not initializing it properly.
 	 */
-	bmips_rac_flush_disable = !!(read_c0_brcm_cmt_local() & (1 << 31));
+	bmips_rac_flush_disable = !!(read_c0_brcm_cmt_local() & (1 << 31)) ||
+				  !!BMIPS_GET_CBR();
 }
 
 static void bcm6368_quirks(void)
-- 
2.43.0

On Tue, Jun 11, 2024 at 01:35:33PM +0200, Christian Marangi wrote:
> It was discovered that some device have CBR address set to 0 causing
> kernel panic when arch_sync_dma_for_cpu_all is called.
> 
> This was notice in situation where the system is booted from TP1 and
> BMIPS_GET_CBR() returns 0 instead of a valid address and
> !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
> 
> The current check whether RAC flush should be disabled or not are not
> enough hence lets check if CBR is a valid address or not.
> 
> Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
>  arch/mips/bmips/setup.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

applied to mips-fixes.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

On Tue, Jun 11, 2024 at 01:35:33PM +0200, Christian Marangi wrote:
> It was discovered that some device have CBR address set to 0 causing
> kernel panic when arch_sync_dma_for_cpu_all is called.
> 
> This was notice in situation where the system is booted from TP1 and
> BMIPS_GET_CBR() returns 0 instead of a valid address and
> !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
> 
> The current check whether RAC flush should be disabled or not are not
> enough hence lets check if CBR is a valid address or not.
> 
> Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")

should I apply it to mips-fixes ? If not could you just ammend
it with the following patch, where this is changed again ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

On Tue, Jun 11, 2024 at 02:49:07PM +0200, Thomas Bogendoerfer wrote:
> On Tue, Jun 11, 2024 at 01:35:33PM +0200, Christian Marangi wrote:
> > It was discovered that some device have CBR address set to 0 causing
> > kernel panic when arch_sync_dma_for_cpu_all is called.
> > 
> > This was notice in situation where the system is booted from TP1 and
> > BMIPS_GET_CBR() returns 0 instead of a valid address and
> > !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
> > 
> > The current check whether RAC flush should be disabled or not are not
> > enough hence lets check if CBR is a valid address or not.
> > 
> > Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")
> 
> should I apply it to mips-fixes ? If not could you just ammend
> it with the following patch, where this is changed again ?
>

Ideally this should be backported to stable kernel since it does cause
kernel panic. This is why it's split and it's the first patch of the
series.

-- 
	Ansuel

On Tue, Jun 11, 2024 at 03:04:36PM +0200, Christian Marangi wrote:
> On Tue, Jun 11, 2024 at 02:49:07PM +0200, Thomas Bogendoerfer wrote:
> > On Tue, Jun 11, 2024 at 01:35:33PM +0200, Christian Marangi wrote:
> > > It was discovered that some device have CBR address set to 0 causing
> > > kernel panic when arch_sync_dma_for_cpu_all is called.
> > > 
> > > This was notice in situation where the system is booted from TP1 and
> > > BMIPS_GET_CBR() returns 0 instead of a valid address and
> > > !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
> > > 
> > > The current check whether RAC flush should be disabled or not are not
> > > enough hence lets check if CBR is a valid address or not.
> > > 
> > > Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")
> > 
> > should I apply it to mips-fixes ? If not could you just ammend
> > it with the following patch, where this is changed again ?
> >
> 
> Ideally this should be backported to stable kernel since it does cause
> kernel panic. This is why it's split and it's the first patch of the
> series.

ok, I'll apply it to mips-fixes then.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]