[PATCH] 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 <redacted>
---
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(-)

diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
index 182034d2ef58..53b71fe50767 100644
--- a/drivers/pcmcia/m8xx_pcmcia.c
+++ b/drivers/pcmcia/m8xx_pcmcia.c

@@ -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);
 

-- 
1.9.0

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


Paul Bolle

On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:

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 <redacted>
---
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(-)

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

On Thu, 2014-05-29 at 13:20 -0500, Scott Wood wrote:

On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:

quoted

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 <redacted>
---
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(-)

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?

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
    linux-pcmcia@lists.infradead.org (open list:PCMCIA SUBSYSTEM)
    linux-kernel@vger.kernel.org (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

On Thu, 2014-05-29 at 20:39 +0200, Paul Bolle wrote:

On Thu, 2014-05-29 at 13:20 -0500, Scott Wood wrote:

quoted

On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:

quoted

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 <redacted>
---
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(-)

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

On Thu, 2014-05-29 at 20:39 +0200, Paul Bolle wrote:

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

Not involved in 8xx activities for years, update MAINTAINERS
to reflect it.

Signed-off-by: Marcelo Tosatti <redacted>

diff --git a/MAINTAINERS b/MAINTAINERS
index c47d268..ed7b606 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -5349,7 +5349,6 @@ F:	arch/powerpc/*/*/*virtex*
 
 LINUX FOR POWERPC EMBEDDED PPC8XX
 M:	Vitaly Bordug <vitb@kernel.crashing.org>
-M:	Marcelo Tosatti <marcelo@kvack.org>
 W:	http://www.penguinppc.org/
 L:	linuxppc-dev@lists.ozlabs.org
 S:	Maintained