Skip to contentSkip to conversation

pcmcia: m8xx: remove checks for four macros

PATCH In review Paul Bolle 3 participants 7 messages May 24, 2014 – May 29, 2014 Pcmcia

lore
Share & tools
lore

Paul Bolle

author
#0 lore raw

PATCH 1/1 pcmcia: m8xx: remove checks for four macros

This driver contains checks for four Kconfig macros. But the related Kconfig symbols have never been part of the tree. Remove these checks and the code they hide.

Signed-off-by Paul Bolle <[email protected]>

---
Untested.

This has been an issue ever since this driver was added in v2.6.15. Note that there is no header named "*/cpld.h", so setting PRxK can't possibly work.

 drivers/pcmcia/m8xx_pcmcia.c | 75 --------------------------------------------
 1 file changed, 75 deletions(-)
drivers/pcmcia/m8xx_pcmcia.c +0 -75
index 182034d2ef58..53b71fe50767 100644
@@ -78,24 +78,14 @@ MODULE_LICENSE("Dual MPL/GPL");
 
 /* The FADS series are a mess */
 #ifdef CONFIG_FADS
-#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821)
-#define CONFIG_PCMCIA_SLOT_A
-#else
 #define CONFIG_PCMCIA_SLOT_B
 #endif
-#endif
 
 #if defined(CONFIG_MPC885ADS)
 #define CONFIG_PCMCIA_SLOT_A
 #define PCMCIA_GLITCHY_CD
 #endif
 
-/* Cyclades ACS uses both slots */
-#ifdef CONFIG_PRxK
-#define CONFIG_PCMCIA_SLOT_A
-#define CONFIG_PCMCIA_SLOT_B
-#endif
-
 #endif				/* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
 
 #if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)

@@ -340,71 +330,6 @@ static inline int voltage_set(int slot, int vcc, int vpp)
 
 #endif
 
-#if defined(CONFIG_PRxK)
-#include <asm/cpld.h>
-extern volatile fpga_pc_regs *fpga_pc;
-
-#define PCMCIA_BOARD_MSG "MPC855T"
-
-static int voltage_set(int slot, int vcc, int vpp)
-{
-	u8 reg = 0;
-	u8 regread;
-	cpld_regs *ccpld = get_cpld();
-
-	switch (vcc) {
-	case 0:
-		break;
-	case 33:
-		reg |= PCMCIA_VCC_33;
-		break;
-	case 50:
-		reg |= PCMCIA_VCC_50;
-		break;
-	default:
-		return 1;
-	}
-
-	switch (vpp) {
-	case 0:
-		break;
-	case 33:
-	case 50:
-		if (vcc == vpp)
-			reg |= PCMCIA_VPP_VCC;
-		else
-			return 1;
-		break;
-	case 120:
-		if ((vcc == 33) || (vcc == 50))
-			reg |= PCMCIA_VPP_12;
-		else
-			return 1;
-	default:
-		return 1;
-	}
-
-	reg = reg >> (slot << 2);
-	regread = in_8(&ccpld->fpga_pc_ctl);
-	if (reg !=
-	    (regread & ((PCMCIA_VCC_MASK | PCMCIA_VPP_MASK) >> (slot << 2)))) {
-		/* enable new powersettings */
-		regread =
-		    regread & ~((PCMCIA_VCC_MASK | PCMCIA_VPP_MASK) >>
-				(slot << 2));
-		out_8(&ccpld->fpga_pc_ctl, reg | regread);
-		msleep(100);
-	}
-
-	return 0;
-}
-
-#define socket_get(_slot_) PCMCIA_SOCKET_KEY_LV
-#define hardware_enable(_slot_)	/* No hardware to enable */
-#define hardware_disable(_slot_)	/* No hardware to disable */
-
-#endif				/* CONFIG_PRxK */
-
 static u32 pending_events[PCMCIA_SOCKETS_NO];
 static DEFINE_SPINLOCK(pending_event_lock);
Signature · 1 line
1.9.0
author
#1 lore raw

The message to Marcelo's address bounced. Does that always happen?

Paul Bolle

#2 lore raw
In reply to Paul Bolle
Quoted 8 lines · Paul Bolle

This driver contains checks for four Kconfig macros. But the related Kconfig symbols have never been part of the tree. Remove these checks and the code they hide.

Signed-off-by Paul Bolle <[email protected]>

---
Untested.

Quoted 6 lines

This has been an issue ever since this driver was added in v2.6.15. Note that there is no header named "*/cpld.h", so setting PRxK can't possibly work.

 drivers/pcmcia/m8xx_pcmcia.c | 75 --------------------------------------------
 1 file changed, 75 deletions(-)

Does anything in this driver still work? It looks like bitrot from the arch/ppc days, that sort of got updated to use the device tree -- but even after this patch there are lots of instances of CONFIG symbols being used to assert the exact hardware being used, rather than what hardware is supported.

Is anyone actively maintaining/testing this code?

-Sott

author
#3 lore raw
Quoted 13 lines · Scott Wood
Quoted 12 lines · Paul Bolle

This driver contains checks for four Kconfig macros. But the related Kconfig symbols have never been part of the tree. Remove these checks and the code they hide.

Signed-off-by Paul Bolle <[email protected]>

---
Untested.

This has been an issue ever since this driver was added in v2.6.15. Note that there is no header named "*/cpld.h", so setting PRxK can't possibly work.

Quoted 8 lines
Quoted 2 lines
 drivers/pcmcia/m8xx_pcmcia.c | 75 --------------------------------------------
 1 file changed, 75 deletions(-)

Does anything in this driver still work? It looks like bitrot from the arch/ppc days, that sort of got updated to use the device tree -- but even after this patch there are lots of instances of CONFIG symbols being used to assert the exact hardware being used, rather than what hardware is supported.

I'm not sure I get what you're pointing at. Can you give one example?

Quoted 1 line

Is anyone actively maintaining/testing this code?

Related observation: doing

    scripts/get_maintainer.pl -f drivers/pcmcia/m8xx_pcmcia.c --no-git-fallback --no-keywords

just gave me
[email protected] (open list:PCMCIA SUBSYSTEM) [email protected] (open list)

Note that there's no person responsible for PCMCIA. That's why I included the people (and lists) maintaining PPC8XX and PPC.

Paul Bolle

#4 lore raw
Quoted 17 lines · Paul Bolle
Quoted 16 lines · Scott Wood
Quoted 14 lines · Paul Bolle

This driver contains checks for four Kconfig macros. But the related Kconfig symbols have never been part of the tree. Remove these checks and the code they hide.

Signed-off-by Paul Bolle <[email protected]>

---
Untested.

This has been an issue ever since this driver was added in v2.6.15. Note that there is no header named "*/cpld.h", so setting PRxK can't possibly work.

 drivers/pcmcia/m8xx_pcmcia.c | 75 --------------------------------------------
 1 file changed, 75 deletions(-)
Quoted 7 lines
Quoted 5 lines

Does anything in this driver still work? It looks like bitrot from the arch/ppc days, that sort of got updated to use the device tree -- but even after this patch there are lots of instances of CONFIG symbols being used to assert the exact hardware being used, rather than what hardware is supported.

I'm not sure I get what you're pointing at. Can you give one example?

All the various stuff enabled by CONFIG_FADS, CONFIG_MPC885ADS, etc. such as the voltage_set() implementation.

-Scott

author
#5 lore raw
In reply to Paul Bolle
Quoted 2 lines · Paul Bolle

That's why I included the people (and lists) maintaining PPC8XX and PPC.

And of those people Marcelo might consider replacing the bouncing knack.org address with a redhat.com address. Provided Marcelo still cares about PPC8XX, that is. But perhaps there are two Marcelo Tosatti's working on the kernel.

Paul Bolle