MIPS: cleanup switches with cases that can be merged

PATCH In review Roel Kluin 5 participants 9 messages Jan 19, 2010 – Jan 25, 2010 MIPS

Share & tools

Roel Kluin

author

2010-01-19 23:54 UTC #0 lore raw

PATCH 1/1 MIPS: cleanup switches with cases that can be merged

I did a search for switch statements with cases that can be merged, but maybe some were not intended? ---------------->8------------------------------------------8<----------------- In these cases the same code was executed.

Signed-off-by Roel Kluin <[email protected]>

---
 arch/mips/include/asm/octeon/octeon-feature.h |    8 ++------
 arch/mips/kernel/cpu-probe.c                  |    3 ---
 arch/mips/math-emu/ieee754dp.c                |    1 -
 arch/mips/math-emu/ieee754sp.c                |    1 -
 arch/mips/pci/pci-octeon.c                    |    6 ++----
 arch/mips/powertv/asic/asic_devices.c         |    4 ----
 arch/mips/sgi-ip32/ip32-irq.c                 |    9 +--------
 7 files changed, 5 insertions(+), 27 deletions(-)

arch/mips/include/asm/octeon/octeon-feature.h +2 -6

index ef24a7b..cba6fbe 100644
@@ -99,6 +99,8 @@ static inline int octeon_has_feature(enum octeon_feature feature)
 		return !cvmx_fuse_read(90);
 
 	case OCTEON_FEATURE_PCIE:
+	case OCTEON_FEATURE_MGMT_PORT:
+	case OCTEON_FEATURE_RAID:
 		return OCTEON_IS_MODEL(OCTEON_CN56XX)
 			|| OCTEON_IS_MODEL(OCTEON_CN52XX);

@@ -110,12 +112,6 @@ static inline int octeon_has_feature(enum octeon_feature feature)
 	case OCTEON_FEATURE_TRA:
 		return !(OCTEON_IS_MODEL(OCTEON_CN30XX)
 			 || OCTEON_IS_MODEL(OCTEON_CN50XX));
-	case OCTEON_FEATURE_MGMT_PORT:
-		return OCTEON_IS_MODEL(OCTEON_CN56XX)
-			|| OCTEON_IS_MODEL(OCTEON_CN52XX);
-	case OCTEON_FEATURE_RAID:
-		return OCTEON_IS_MODEL(OCTEON_CN56XX)
-			|| OCTEON_IS_MODEL(OCTEON_CN52XX);
 	case OCTEON_FEATURE_USB:
 		return !(OCTEON_IS_MODEL(OCTEON_CN38XX)
 			 || OCTEON_IS_MODEL(OCTEON_CN58XX));

arch/mips/kernel/cpu-probe.c +0 -3

index 80e202e..603e3bd 100644
@@ -722,9 +722,6 @@ static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
 		__cpu_name[cpu] = "MIPS 4Kc";
 		break;
 	case PRID_IMP_4KEC:
-		c->cputype = CPU_4KEC;
-		__cpu_name[cpu] = "MIPS 4KEc";
-		break;
 	case PRID_IMP_4KECR2:
 		c->cputype = CPU_4KEC;
 		__cpu_name[cpu] = "MIPS 4KEc";

arch/mips/math-emu/ieee754dp.c +0 -1

index 6d2d89f..2f22fd7 100644
@@ -148,7 +148,6 @@ ieee754dp ieee754dp_format(int sn, int xe, u64 xm)
 
 			switch(ieee754_csr.rm) {
 			case IEEE754_RN:
-				return ieee754dp_zero(sn);
 			case IEEE754_RZ:
 				return ieee754dp_zero(sn);
 			case IEEE754_RU:    /* toward +Infinity */

arch/mips/math-emu/ieee754sp.c +0 -1

index 4635340..a19b721 100644
@@ -149,7 +149,6 @@ ieee754sp ieee754sp_format(int sn, int xe, unsigned xm)
 
 			switch(ieee754_csr.rm) {
 			case IEEE754_RN:
-				return ieee754sp_zero(sn);
 			case IEEE754_RZ:
 				return ieee754sp_zero(sn);
 			case IEEE754_RU:      /* toward +Infinity */

arch/mips/pci/pci-octeon.c +2 -4

index 9cb0c80..d248b70 100644
@@ -209,16 +209,14 @@ const char *octeon_get_pci_interrupts(void)
 	case CVMX_BOARD_TYPE_NAO38:
 		/* This is really the NAC38 */
 		return "AAAAADABAAAAAAAAAAAAAAAAAAAAAAAA";
-	case CVMX_BOARD_TYPE_THUNDER:
-		return "";
-	case CVMX_BOARD_TYPE_EBH3000:
-		return "";
 	case CVMX_BOARD_TYPE_EBH3100:
 	case CVMX_BOARD_TYPE_CN3010_EVB_HS5:
 	case CVMX_BOARD_TYPE_CN3005_EVB_HS5:
 		return "AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
 	case CVMX_BOARD_TYPE_BBGW_REF:
 		return "AABCD";
+	case CVMX_BOARD_TYPE_THUNDER:
+	case CVMX_BOARD_TYPE_EBH3000:
 	default:
 		return "";
 	}

arch/mips/powertv/asic/asic_devices.c +0 -4

index bae8288..36dbcad 100644
@@ -340,10 +340,6 @@ static void __init platform_configure_usb(void)
 
 	switch (asic) {
 	case ASIC_ZEUS:
-		fs_update(0x0000, 0x11, 0x02, 0);
-		bcm1_usb2_ctl = 0x803;
-		break;
-
 	case ASIC_CRONUS:
 	case ASIC_CRONUSLITE:
 		fs_update(0x0000, 0x11, 0x02, 0);

arch/mips/sgi-ip32/ip32-irq.c +1 -8

index 5c2bf11..d8b6520 100644
@@ -512,10 +512,6 @@ void __init arch_init_irq(void)
 				"level");
 			break;
 
-		case CRIME_GBE0_IRQ ... CRIME_GBE3_IRQ:
-			set_irq_chip_and_handler_name(irq,
-				&crime_edge_interrupt, handle_edge_irq, "edge");
-			break;
 		case CRIME_CPUERR_IRQ:
 		case CRIME_MEMERR_IRQ:
 			set_irq_chip_and_handler_name(irq,

@@ -523,12 +519,9 @@ void __init arch_init_irq(void)
 				"level");
 			break;
 
+		case CRIME_GBE0_IRQ ... CRIME_GBE3_IRQ:
 		case CRIME_RE_EMPTY_E_IRQ ... CRIME_RE_IDLE_E_IRQ:
 		case CRIME_SOFT0_IRQ ... CRIME_SOFT2_IRQ:
-			set_irq_chip_and_handler_name(irq,
-				&crime_edge_interrupt, handle_edge_irq, "edge");
-			break;
-
 		case CRIME_VICE_IRQ:
 			set_irq_chip_and_handler_name(irq,
 				&crime_edge_interrupt, handle_edge_irq, "edge");

David Daney

2010-01-20 02:03 UTC #1 lore raw

Quoted 6 lines · Roel Kluin

I did a search for switch statements with cases that can be merged, but maybe some were not intended? ---------------->8------------------------------------------8<----------------- In these cases the same code was executed.
Signed-off-by Roel Kluin <[email protected]>

Quoted 9 lines

---
 arch/mips/include/asm/octeon/octeon-feature.h |    8 ++------
 arch/mips/kernel/cpu-probe.c                  |    3 ---
 arch/mips/math-emu/ieee754dp.c                |    1 -
 arch/mips/math-emu/ieee754sp.c                |    1 -
 arch/mips/pci/pci-octeon.c                    |    6 ++----
 arch/mips/powertv/asic/asic_devices.c         |    4 ----
 arch/mips/sgi-ip32/ip32-irq.c                 |    9 +--------
 7 files changed, 5 insertions(+), 27 deletions(-)

This patch should be split up.

Octeon, PowerTV, and IP32 are all different architectures. They should be in their own patches.

The two math-emu parts could probably go together.

cpu-probe seems like its own thing.

This brings us to the larger question: This is just code churn. Is it even worthwhile?

David Daney

Alexander Clouter

2010-01-20 12:08 UTC #2 lore raw

Quoted 6 lines · In gmane.linux.ports.mips.general David Daney

[snipped]
This brings us to the larger question: This is just code churn. Is it even worthwhile?

Anything which reduces the line count and remove duplication whilst sticking to CodingStyle I would always argue for, but "who am I" :)

It at a glance, this type of code churn, shows there are no differences between two classes of <whatever> and the effect is it makes the chunk of code a mental NOOP for the person reading the code. :)

To me this is a natural extension of running with Chapter 14 of CodingStyle where you kmalloc using 'sizeof(*p)' rather than 'sizeof(struct *foo)' so reducing the chance of errors later on.

Just my thoughts.

Cheers

Signature · 2 lines

Alexander Clouter
.sigmonster says: Snoopy: No problem is so big that it can't be run away from.

Ralf Baechle

2010-01-23 16:32 UTC #3 lore raw

In reply to David Daney

Quoted 8 lines · David Daney

This patch should be split up.
Octeon, PowerTV, and IP32 are all different architectures. They should be in their own patches.
The two math-emu parts could probably go together.
cpu-probe seems like its own thing.

It's conceptually the same change that's being applied everywhere and the total size is modest so I'm happy to apply it as just a single patch as is.

Quoted 2 lines

This brings us to the larger question: This is just code churn. Is it even worthwhile?

This has been discussed many times over and we maintainers have not come to a final conclusion on this type of patches. I tend to apply this sort of patches anyway but treat them as low priority.

Ralf

Ralf Baechle

2010-01-24 00:23 UTC #4 lore raw

In reply to Roel Kluin

Quoted 4 lines · Roel Kluin

I did a search for switch statements with cases that can be merged, but maybe some were not intended? ---------------->8------------------------------------------8<----------------- In these cases the same code was executed.

Queued for 2.6.34.

Ralf

Anoop P.A.

2010-01-24 17:58 UTC #5 lore raw

1 GB RAM with RM9000 SOC

Hi list,

Any of you successfully used >512MB ram with MIPS SOC's. I have a requirement where I have to use 1 GB ram with RM9000 based SOC.

I have enabled 64 Bit support and so far it is working with 512 MB of RAM. How ever if I increase memory beyond 512MB I am getting kernel panic.

I am adding memory region from 0x00 add_memory_region(0 ,0x40000000 ,
BOOT_MEM_RAM). (PMON maps RAM from 0x0 to 0x40000000) Am I wrong here?

It will be great if you can give some suggestion /point me to a working implementation. I am using 2.6.18 kernel.

Thanks

Anoop

David Daney

2010-01-25 17:16 UTC #6 lore raw

Re: 1 GB RAM with RM9000 SOC

Quoted 5 lines · Anoop P.A.

Hi list,
Any of you successfully used >512MB ram with MIPS SOC's.

Does Cavium Octeon count as a MIPS SOC? If so, then yes.

I have many boards with both 2GB and 4GB. All of them Linux just fine when using all available RAM.

Quoted 26 lines

I have a
requirement where I have to use 1 GB ram with RM9000 based SOC.
I have enabled 64 Bit support and so far it is working with 512 MB of RAM. How ever if I increase memory beyond 512MB I am getting kernel panic.
I am adding memory region from 0x00 add_memory_region(0 ,0x40000000 ,
BOOT_MEM_RAM). (PMON maps RAM from 0x0 to 0x40000000) Am I wrong here?
It will be great if you can give some suggestion /point me to a working implementation. I am using 2.6.18 kernel.
Thanks
Anoop

Anoop P.A.

2010-01-25 17:34 UTC #7 lore raw

RE: 1 GB RAM with RM9000 SOC

Hi David,

Thanks for the info. In which version of LMO kernel , I could find your working source ?.

Thanks
Anoop

Quoted 12 lines

-----Original Message-----
From: David Daney [mailto:[email protected]]
Sent: Monday, January 25, 2010 10:45 PM
To: Anoop P.A.
Cc: [email protected]
Subject: Re: 1 GB RAM with RM9000 SOC
Quoted 4 lines · Anoop P.A.
Hi list,

Quoted 11 lines

Quoted 1 line
Any of you successfully used >512MB ram with MIPS SOC's.
Does Cavium Octeon count as a MIPS SOC? If so, then yes.
I have many boards with both 2GB and 4GB. All of them Linux just fine when using all available RAM.
Quoted 4 lines
I have a
requirement where I have to use 1 GB ram with RM9000 based SOC.
I have enabled 64 Bit support and so far it is working with 512 MB

Quoted 6 lines

Quoted 6 lines
RAM. How ever if I increase memory beyond 512MB I am getting kernel panic.
I am adding memory region from 0x00 add_memory_region(0 ,0x40000000

Quoted 1 line

Quoted 1 line
BOOT_MEM_RAM). (PMON maps RAM from 0x0 to 0x40000000) Am I wrong

here?

Quoted 4 lines

Quoted 4 lines
It will be great if you can give some suggestion /point me to a

working

Quoted 11 lines

Quoted 11 lines
implementation. I am using 2.6.18 kernel.
Thanks
Anoop

David Daney

2010-01-25 17:39 UTC #8 lore raw

Re: 1 GB RAM with RM9000 SOC

Quoted 5 lines · Anoop P.A.

Hi David,
Thanks for the info. In which version of LMO kernel , I could find your working source ?.

I think it was added in 2.6.29

David Daney

Quoted 52 lines

Thanks
Anoop
Quoted 12 lines
-----Original Message-----
From: David Daney [mailto:[email protected]]
Sent: Monday, January 25, 2010 10:45 PM
To: Anoop P.A.
Cc: [email protected]
Subject: Re: 1 GB RAM with RM9000 SOC
Quoted 4 lines · Anoop P.A.
Hi list,
Quoted 10 lines
Quoted 1 line
Any of you successfully used >512MB ram with MIPS SOC's.
Does Cavium Octeon count as a MIPS SOC? If so, then yes.
I have many boards with both 2GB and 4GB. All of them Linux just fine when using all available RAM.
Quoted 4 lines
I have a
requirement where I have to use 1 GB ram with RM9000 based SOC.
I have enabled 64 Bit support and so far it is working with 512 MB
of
Quoted 6 lines
Quoted 6 lines
RAM. How ever if I increase memory beyond 512MB I am getting kernel panic.
I am adding memory region from 0x00 add_memory_region(0 ,0x40000000
,
Quoted 1 line
Quoted 1 line
BOOT_MEM_RAM). (PMON maps RAM from 0x0 to 0x40000000) Am I wrong
here?
Quoted 3 lines
Quoted 3 lines
It will be great if you can give some suggestion /point me to a
working
Quoted 11 lines
Quoted 11 lines
implementation. I am using 2.6.18 kernel.
Thanks
Anoop