[PATCH] [RESEND] pcmcia: badge4: avoid unused function warning

2017-09-11 Thread Arnd Bergmann 
The pcmv_setup is only used when the badge4 driver is built-in, but
not when it is a loadable module:

drivers/pcmcia/sa_badge4.c:153:122: error: 'pcmv_setup' defined but not 
used [-Werror=unused-function]

This adds an #ifdef to avoid the definition of the unused function
in the modular case.

Signed-off-by: Arnd Bergmann 
---
Patch was sent on Jan 25 2016, and on July 21, 2017 but got no
reply.

Andrew, could you pick it up?
---
 drivers/pcmcia/sa_badge4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pcmcia/sa_badge4.c b/drivers/pcmcia/sa_badge4.c
index 2f490930430d..93a5c7423d80 100644
--- a/drivers/pcmcia/sa_badge4.c
+++ b/drivers/pcmcia/sa_badge4.c
@@ -144,6 +144,7 @@ int pcmcia_badge4_init(struct sa_dev *dev)
 sa11xx_drv_pcmcia_add_one);
 }
 
+#ifndef MODULE
 static int __init pcmv_setup(char *s)
 {
int v[4];
@@ -158,3 +159,4 @@ static int __init pcmv_setup(char *s)
 }
 
 __setup("pcmv=", pcmv_setup);
+#endif
-- 
2.9.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH] [RESEND] pcmcia: badge4: avoid unused function warning

2017-07-21 Thread Arnd Bergmann 
The pcmv_setup is only used when the badge4 driver is built-in, but
not when it is a loadable module:

drivers/pcmcia/sa_badge4.c:153:122: error: 'pcmv_setup' defined but not 
used [-Werror=unused-function]

This adds an #ifdef to avoid the definition of the unused function
in the modular case.

Signed-off-by: Arnd Bergmann 
---
Patch was sent on Jan 25 2016, no reply, resending
---
 drivers/pcmcia/sa_badge4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pcmcia/sa_badge4.c b/drivers/pcmcia/sa_badge4.c
index 2f490930430d..93a5c7423d80 100644
--- a/drivers/pcmcia/sa_badge4.c
+++ b/drivers/pcmcia/sa_badge4.c
@@ -144,6 +144,7 @@ int pcmcia_badge4_init(struct sa_dev *dev)
 sa11xx_drv_pcmcia_add_one);
 }
 
+#ifndef MODULE
 static int __init pcmv_setup(char *s)
 {
int v[4];
@@ -158,3 +159,4 @@ static int __init pcmv_setup(char *s)
 }
 
 __setup("pcmv=", pcmv_setup);
+#endif
-- 
2.9.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

2017-03-16 Thread Arnd Bergmann 
On Thu, Mar 16, 2017 at 10:55 AM, Michael Ellerman  wrote:
> Arnd Bergmann  writes:
>> On Wed, Mar 15, 2017 at 6:35 AM, Michael Ellerman  
>> wrote:
>>> I'll do patches for everything above that's not drivers/soc or
>>> include/soc and hopefully we can hear from someone at NXP on the plans
>>> for getting the soc parts enabled on arm.
>>
>> I think the removal of the NO_IRQ references is a requirement for
>> getting the drivers working properly on ARM, as the OF platform
>> code will use '0' for invalid IRQs.
>
> OK. So the #define NO_IRQ (-1) in arch/arm/include/asm/irq.h is a red
> herring and should be ignored for anything modern?

Correct. There are a couple of older (non-DT) platforms that still rely on it,
and I also have patches for those, which I intend to revisit at some point.

 Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

2017-03-15 Thread Arnd Bergmann 
On Wed, Mar 15, 2017 at 6:35 AM, Michael Ellerman  wrote:
> Arnd Bergmann  writes:
>> On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman  
>> wrote:
>>> Michael Ellerman  writes:
>>>
>>
>> drivers/ata/pata_mpc52xx.c: if (ata_irq == NO_IRQ) {
>> drivers/ata/sata_dwc_460ex.c:#ifndef NO_IRQ
>> drivers/ata/sata_dwc_460ex.c:#define NO_IRQ 0
>> drivers/ata/sata_dwc_460ex.c:   if (hsdev->dma->irq == NO_IRQ) {
>> drivers/ata/sata_dwc_460ex.c:   if (irq == NO_IRQ) {
>> drivers/iommu/fsl_pamu.c:   if (irq == NO_IRQ) {
>> drivers/iommu/fsl_pamu.c:   if (irq != NO_IRQ)
>> drivers/media/platform/fsl-viu.c:   if (viu_irq == NO_IRQ) {
>> drivers/mtd/nand/mpc5121_nfc.c: if (prv->irq == NO_IRQ) {
>> drivers/pcmcia/electra_cf.c:cf->irq = NO_IRQ;
>> drivers/pcmcia/electra_cf.c:if (cf->irq != NO_IRQ)
>> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
>> no interrupt is pending. */
>> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
>> drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
>> no interrupt is pending. */
>> drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
>> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_low == NO_IRQ) {
>> drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_high != NO_IRQ &&
>> drivers/spi/spi-mpc52xx.c:  if (status && (irq != NO_IRQ))
>> drivers/tty/ehv_bytechan.c: if (stdout_irq == NO_IRQ) {
>> drivers/tty/ehv_bytechan.c: if ((bc->rx_irq == NO_IRQ) ||
>> (bc->tx_irq == NO_IRQ)) {
>> drivers/tty/serial/cpm_uart/cpm_uart_core.c:if (pinfo->port.irq == 
>> NO_IRQ) {
>> drivers/uio/uio_fsl_elbc_gpcm.c:if (irq != NO_IRQ) {
>> drivers/uio/uio_fsl_elbc_gpcm.c:irq = NO_IRQ;
>> drivers/uio/uio_fsl_elbc_gpcm.c: irq != NO_IRQ ? irq : -1);
>> drivers/usb/host/ehci-grlib.c:  if (irq == NO_IRQ) {
>> drivers/usb/host/ehci-ppc-of.c: if (irq == NO_IRQ) {
>> drivers/usb/host/fhci-hcd.c:if (usb_irq == NO_IRQ) {
>> drivers/usb/host/ohci-ppc-of.c: if (irq == NO_IRQ) {
>> drivers/usb/host/uhci-grlib.c:  if (irq == NO_IRQ) {
>> drivers/video/fbdev/mb862xx/mb862xxfbdrv.c: if (par->irq == NO_IRQ) {
>> drivers/virt/fsl_hypervisor.c:  if (!handle || (irq == NO_IRQ)) {
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq == NO_IRQ)
>> include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
>>
>> Did you have other pending patches for those?
>
> No. I stayed away from anything FSL related as I was under the
> impression some of them were being ported to arch/arm, which uses -1 for
> NO_IRQ IIUIC.
>
> eg. all of include/soc/fsl and drivers/soc/fsl was moved from
> arch/powerpc in commit 7aa1aa6ecec2, which said:
>
> QE: Move QE from arch/powerpc to drivers/soc
>
> ls1 has qe and ls1 has arm cpu.
> move qe from arch/powerpc to drivers/soc/fsl
> to adapt to powerpc and arm
>
> But looking at the Kconfigs it looks like they're still only selectable
> on PPC. So that's a bit annoying.
>
> I'll do patches for everything above that's not drivers/soc or
> include/soc and hopefully we can hear from someone at NXP on the plans
> for getting the soc parts enabled on arm.

I think the removal of the NO_IRQ references is a requirement for
getting the drivers working properly on ARM, as the OF platform
code will use '0' for invalid IRQs.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] drivers/pcmcia: NO_IRQ removal for electra_cf.c

2017-03-14 Thread Arnd Bergmann 
On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman  wrote:
> Michael Ellerman  writes:
>
>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>> from electra_cf.c which is a powerpc-only driver.
>>
>> Signed-off-by: Michael Ellerman 
>> ---
>>  drivers/pcmcia/electra_cf.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ping anyone?
>
> Or should I merge this via the powerpc tree?

That's what I would recommend for a powerpc specific pcmcia driver, yes.

Looking at the bigger picture of powerpc drivers using NO_IRQ, I also
see these others:

drivers/ata/pata_mpc52xx.c: if (ata_irq == NO_IRQ) {
drivers/ata/sata_dwc_460ex.c:#ifndef NO_IRQ
drivers/ata/sata_dwc_460ex.c:#define NO_IRQ 0
drivers/ata/sata_dwc_460ex.c:   if (hsdev->dma->irq == NO_IRQ) {
drivers/ata/sata_dwc_460ex.c:   if (irq == NO_IRQ) {
drivers/iommu/fsl_pamu.c:   if (irq == NO_IRQ) {
drivers/iommu/fsl_pamu.c:   if (irq != NO_IRQ)
drivers/media/platform/fsl-viu.c:   if (viu_irq == NO_IRQ) {
drivers/mtd/nand/mpc5121_nfc.c: if (prv->irq == NO_IRQ) {
drivers/pcmcia/electra_cf.c:cf->irq = NO_IRQ;
drivers/pcmcia/electra_cf.c:if (cf->irq != NO_IRQ)
drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
no interrupt is pending. */
drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
drivers/soc/fsl/qe/qe_ic.c:/* Return an interrupt vector or NO_IRQ if
no interrupt is pending. */
drivers/soc/fsl/qe/qe_ic.c: return NO_IRQ;
drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_low == NO_IRQ) {
drivers/soc/fsl/qe/qe_ic.c: if (qe_ic->virq_high != NO_IRQ &&
drivers/spi/spi-mpc52xx.c:  if (status && (irq != NO_IRQ))
drivers/tty/ehv_bytechan.c: if (stdout_irq == NO_IRQ) {
drivers/tty/ehv_bytechan.c: if ((bc->rx_irq == NO_IRQ) ||
(bc->tx_irq == NO_IRQ)) {
drivers/tty/serial/cpm_uart/cpm_uart_core.c:if (pinfo->port.irq == NO_IRQ) {
drivers/uio/uio_fsl_elbc_gpcm.c:if (irq != NO_IRQ) {
drivers/uio/uio_fsl_elbc_gpcm.c:irq = NO_IRQ;
drivers/uio/uio_fsl_elbc_gpcm.c: irq != NO_IRQ ? irq : -1);
drivers/usb/host/ehci-grlib.c:  if (irq == NO_IRQ) {
drivers/usb/host/ehci-ppc-of.c: if (irq == NO_IRQ) {
drivers/usb/host/fhci-hcd.c:if (usb_irq == NO_IRQ) {
drivers/usb/host/ohci-ppc-of.c: if (irq == NO_IRQ) {
drivers/usb/host/uhci-grlib.c:  if (irq == NO_IRQ) {
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c: if (par->irq == NO_IRQ) {
drivers/virt/fsl_hypervisor.c:  if (!handle || (irq == NO_IRQ)) {
include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)
include/soc/fsl/qe/qe_ic.h: if (cascade_irq == NO_IRQ)
include/soc/fsl/qe/qe_ic.h: if (cascade_irq != NO_IRQ)

Did you have other pending patches for those?

  Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 16/28] pcmcia: fix return value of soc_pcmcia_regulator_set

2016-10-17 Thread Arnd Bergmann 
The newly introduced soc_pcmcia_regulator_set() function sometimes returns
without setting its return code, as shown by this warning:

drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set':
drivers/pcmcia/soc_common.c:112:5: error: 'ret' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

This changes it to propagate the regulator_disable() result instead.

Fixes: ac61b6001a63 ("pcmcia: soc_common: add support for Vcc and Vpp 
regulators")
Cc: Russell King 
Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/soc_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index 153f312..b6b316d 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -107,7 +107,7 @@ int soc_pcmcia_regulator_set(struct soc_pcmcia_socket *skt,
 
ret = regulator_enable(r->reg);
} else {
-   regulator_disable(r->reg);
+   ret = regulator_disable(r->reg);
}
if (ret == 0)
r->on = on;
-- 
2.9.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 4/4] pcmcia: soc-common: remove incorrect NO_IRQ use

2016-09-06 Thread Arnd Bergmann 
The soc_common driver (used on ARM sa1100 and pxa) initializes the
socket->pci_irq member to NO_IRQ by default to signify an invalid
interrupt, and normally overrides this with a proper interrupt later.

However, the code that checks socked->pci_irq for validity compares
it to zero instead of NO_IRQ, as most drivers do, so this cannot
work right. While zero is a valid interrupt number on PXA (and
in the past also on sa1100), it is the interrupt line for the 'ssp'
serial port, so there is no possible conflict in practice and
we can simply change the default to zero.

Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/soc_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index eed5e9c05353..339ce29fa97b 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -691,7 +691,7 @@ void soc_pcmcia_init_one(struct soc_pcmcia_socket *skt,
skt->ops = ops;
skt->socket.owner = ops->owner;
skt->socket.dev.parent = dev;
-   skt->socket.pci_irq = NO_IRQ;
+   skt->socket.pci_irq = 0;
 
for (i = 0; i < ARRAY_SIZE(skt->stat); i++)
skt->stat[i].gpio = -EINVAL;
-- 
2.9.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH] pcmcia: soc-common: remove incorrect NO_IRQ use

2016-09-06 Thread Arnd Bergmann 
The soc_common driver (used on ARM sa1100 and pxa) initializes the
socket->pci_irq member to NO_IRQ by default to signify an invalid
interrupt, and normally overrides this with a proper interrupt later.

However, the code that checks socked->pci_irq for validity compares
it to zero instead of NO_IRQ, as most drivers do, so this cannot
work right. While zero is a valid interrupt number on PXA (and
in the past also on sa1100), it is the interrupt line for the 'ssp'
serial port, so there is no possible conflict in practice and
we can simply change the default to zero.

Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/soc_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index eed5e9c05353..339ce29fa97b 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -691,7 +691,7 @@ void soc_pcmcia_init_one(struct soc_pcmcia_socket *skt,
skt->ops = ops;
skt->socket.owner = ops->owner;
skt->socket.dev.parent = dev;
-   skt->socket.pci_irq = NO_IRQ;
+   skt->socket.pci_irq = 0;
 
for (i = 0; i < ARRAY_SIZE(skt->stat); i++)
skt->stat[i].gpio = -EINVAL;
-- 
2.9.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] pcmcia: db1xxx_ss: fix last irq_to_gpio user

2016-03-02 Thread Arnd Bergmann 
On Wednesday 02 March 2016 09:16:12 Manuel Lauss wrote:
> remove the usage of removed irq_to_gpio() function.  On pre-DB1200
> boards, pass the actual carddetect GPIO number instead of the IRQ,
> because we need the gpio to actually test card status (inserted or
> not) and can get the irq number with gpio_to_irq() instead.
> 
> Tested on DB1300 and DB1500, this patch fixes PCMCIA on the DB1500,
> which used irq_to_gpio().
> 
> Signed-off-by: Manuel Lauss 

Thanks for addressing this

Acked-by: Arnd Bergmann 

You should probably add the fixes line from my earlier patch,
and add Cc:stable so it gets backported to 4.4.

>  
> - /* insert: irq which triggers on card insertion/ejection */
> + /* insert: irq which triggers on card insertion/ejection
> +  * BIG FAT NOTE: on DB1000/1100/1500/1550 we pass a GPIO here!
> +  */
>   r = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "insert");
>   sock->insert_irq = r ? r->start : -1;
> + if (sock->board_type == BOARD_TYPE_DEFAULT) {
> + sock->insert_gpio = r ? r->start : -1;
> + sock->insert_irq = r ? gpio_to_irq(r->start) : -1;
> + }
>  
>   /* stschg: irq which trigger on card status change (optional) */
>   r = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "stschg");

My first approach was to pass the gpio number as platform_data, but
that seemed to get rather complicated, so I dropped the initial
patch.

Passing it as an IORESOURCE_IRQ is a bit weird too, but I guess it
gets the job done.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] pcmcia: db1xxx: use correct irq_to_gpio helper

2016-03-02 Thread Arnd Bergmann 
On Wednesday 02 March 2016 07:50:28 Manuel Lauss wrote:
> > Signed-off-by: Arnd Bergmann 
> > Cc: sta...@vger.kernel.org # v4.3
> > Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
> > ---
> > I think this is now the last holdout of the irq_to_gpio function,
> > and it's been broken for a while. Maybe Ralf can queue it up through
> > the MIPS tree along with the other fix for irq_to_gpio?
> 
> It's not broken though..  this driver on current linus-git works fine!

Ah, so it doesn't actually need the gpio line then?

irq_to_gpio() unconditionally returns -EINVAL since 4.3, so the easiest
fix would be to remove the card-detect function in the driver, right?

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH] pcmcia: db1xxx: use correct irq_to_gpio helper

2016-03-01 Thread Arnd Bergmann 
After the removal of asm/gpio.h and asm/mach-au1x00/gpio.h, the db1xxx_ss
pcmcia driver picked up the wrong irq_to_gpio function from the generic
headers.

This restores the old __au_irq_to_gpio() implementation, but keeps
it local to the only file that uses it.

It would be nicer to just pass the gpio number from platform code,
but restoring the previous implementation seems safer.

Signed-off-by: Arnd Bergmann 
Cc: sta...@vger.kernel.org # v4.3
Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
---
I think this is now the last holdout of the irq_to_gpio function,
and it's been broken for a while. Maybe Ralf can queue it up through
the MIPS tree along with the other fix for irq_to_gpio?

Linus, maybe you can queue up the include/linux/gpio.h change to
remove the function as well for 4.6. We have two users of this function
on MIPS that are already broken, and adding the patch turns the
runtime bug into a compile-time bug, which seems like a good thing
to me. The other patch is already queued in the mips tree.

diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
index 4c2fa05b4589..41f28879bfef 100644
--- a/drivers/pcmcia/db1xxx_ss.c
+++ b/drivers/pcmcia/db1xxx_ss.c
@@ -35,6 +35,19 @@
 
 #include 
 #include 
+#include 
+#include 
+
+static inline int __au_irq_to_gpio(unsigned int irq)
+{
+   switch (alchemy_get_cputype()) {
+   case ALCHEMY_CPU_AU1000...ALCHEMY_CPU_AU1200:
+   return alchemy_irq_to_gpio(irq);
+   case ALCHEMY_CPU_AU1300:
+   return au1300_irq_to_gpio(irq);
+   }
+   return -EINVAL;
+}
 
 #define MEM_MAP_SIZE   0x40
 #define IO_MAP_SIZE0x1000
@@ -83,7 +96,7 @@ static int db1200_card_inserted(struct db1x_pcmcia_sock *sock)
 /* carddetect gpio: low-active */
 static int db1000_card_inserted(struct db1x_pcmcia_sock *sock)
 {
-   return !gpio_get_value(irq_to_gpio(sock->insert_irq));
+   return !gpio_get_value(__au_irq_to_gpio(sock->insert_irq));
 }
 
 static int db1x_card_inserted(struct db1x_pcmcia_sock *sock)


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH] pcmcia: badge4: avoid unused function warning

2016-01-25 Thread Arnd Bergmann 
The pcmv_setup is only used when the badge4 driver is built-in, but
not when it is a loadable module:

drivers/pcmcia/sa_badge4.c:153:122: error: 'pcmv_setup' defined but not 
used [-Werror=unused-function]

This adds an #ifdef to avoid the definition of the unused function
in the modular case.

Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/sa_badge4.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pcmcia/sa_badge4.c b/drivers/pcmcia/sa_badge4.c
index 12f0dd091477..a57dc1042ba0 100644
--- a/drivers/pcmcia/sa_badge4.c
+++ b/drivers/pcmcia/sa_badge4.c
@@ -150,6 +150,7 @@ int pcmcia_badge4_init(struct sa_dev *dev)
return ret;
 }
 
+#ifndef MODULE
 static int __init pcmv_setup(char *s)
 {
int v[4];
@@ -164,3 +165,4 @@ static int __init pcmv_setup(char *s)
 }
 
 __setup("pcmv=", pcmv_setup);
+#endif
-- 
2.7.0


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 2/4] net: wan: add missing virt_to_bus dependencies

2015-01-28 Thread Arnd Bergmann 
The cosa driver is rather outdated and does not get built on most
platforms because it requires the ISA_DMA_API symbol. However
there are some ARM platforms that have ISA_DMA_API but no virt_to_bus,
and they get this build error when enabling the ltpc driver.

drivers/net/wan/cosa.c: In function 'tx_interrupt':
drivers/net/wan/cosa.c:1768:3: error: implicit declaration of function 
'virt_to_bus'
   unsigned long addr = virt_to_bus(cosa->txbuf);
   ^

The same problem exists for the Hostess SV-11 and Sealevel Systems 4021
drivers.

This adds another dependency in Kconfig to avoid that configuration.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wan/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 94e234975c61..a2fdd15f285a 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -25,7 +25,7 @@ if WAN
 # There is no way to detect a comtrol sv11 - force it modular for now.
 config HOSTESS_SV11
tristate "Comtrol Hostess SV-11 support"
-   depends on ISA && m && ISA_DMA_API && INET && HDLC
+   depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
help
  Driver for Comtrol Hostess SV-11 network card which
  operates on low speed synchronous serial links at up to
@@ -37,7 +37,7 @@ config HOSTESS_SV11
 # The COSA/SRP driver has not been tested as non-modular yet.
 config COSA
tristate "COSA/SRP sync serial boards support"
-   depends on ISA && m && ISA_DMA_API && HDLC
+   depends on ISA && m && ISA_DMA_API && HDLC && VIRT_TO_BUS
---help---
  Driver for COSA and SRP synchronous serial boards.
 
@@ -87,7 +87,7 @@ config LANMEDIA
 # There is no way to detect a Sealevel board. Force it modular
 config SEALEVEL_4021
tristate "Sealevel Systems 4021 support"
-   depends on ISA && m && ISA_DMA_API && INET && HDLC
+   depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
help
  This is a driver for the Sealevel Systems ACB 56 serial I/O adapter.
 
-- 
2.1.0.rc2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 0/4] net: driver fixes from arm randconfig builds

2015-01-28 Thread Arnd Bergmann 
These four patches are fallout from test builds on ARM. I have a
few more of them in my backlog but have not yet confirmed them
to still be valid.

The first three patches are about incomplete dependencies on
old drivers. One could backport them to the beginning of time
in theory, but there is little value since nobody would run into
these problems.

The final patch is one I had submitted before together with the
respective pcmcia patch but forgot to follow up on that. It's
still a valid but relatively theoretical bug, because the previous
behavior of the driver was just as broken as what we have in
mainline.

Please apply,

Arnd

Arnd Bergmann (4):
  net: cs89x0: always build platform code if !HAS_IOPORT_MAP
  net: wan: add missing virt_to_bus dependencies
  net: lance,ni64: don't build for ARM
  net: am2150: fix nmclan_cs.c shared interrupt handling

 drivers/net/ethernet/amd/Kconfig | 4 ++--
 drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
 drivers/net/ethernet/cirrus/Kconfig  | 3 ++-
 drivers/net/wan/Kconfig  | 6 +++---
 4 files changed, 9 insertions(+), 6 deletions(-)

-- 
2.1.0.rc2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 4/4] net: am2150: fix nmclan_cs.c shared interrupt handling

2015-01-28 Thread Arnd Bergmann 
A recent patch tried to work around a valid warning for the use of a
deprecated interface by blindly changing from the old
pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().

This driver has an interrupt handler that is not currently aware
of shared interrupts, but can be easily converted to be.
At the moment, the driver reads the interrupt status register
repeatedly until it contains only zeroes in the interesting bits,
and handles each bit individually.

This patch adds the missing part of returning IRQ_NONE in case none
of the bits are set to start with, so we can move on to the next
interrupt source.

Signed-off-by: Arnd Bergmann 
Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA API")
---
 drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/amd/nmclan_cs.c 
b/drivers/net/ethernet/amd/nmclan_cs.c
index 5b22764ba88d..27245efe9f50 100644
--- a/drivers/net/ethernet/amd/nmclan_cs.c
+++ b/drivers/net/ethernet/amd/nmclan_cs.c
@@ -952,6 +952,8 @@ static irqreturn_t mace_interrupt(int irq, void *dev_id)
   do {
 /* WARNING: MACE_IR is a READ/CLEAR port! */
 status = inb(ioaddr + AM2150_MACE_BASE + MACE_IR);
+if (!(status & ~MACE_IMR_DEFAULT) && IntrCnt == MACE_MAX_IR_ITERATIONS)
+  return IRQ_NONE;
 
 pr_debug("mace_interrupt: irq 0x%X status 0x%X.\n", irq, status);
 
-- 
2.1.0.rc2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 1/4] net: cs89x0: always build platform code if !HAS_IOPORT_MAP

2015-01-28 Thread Arnd Bergmann 
The cs89x0 driver can either be built as an ISA driver or a platform
driver, the choice is controlled by the CS89x0_PLATFORM Kconfig
symbol. Building the ISA driver on a system that does not have
a way to map I/O ports fails with this error:

drivers/built-in.o: In function `cs89x0_ioport_probe.constprop.1':
:(.init.text+0x4794): undefined reference to `ioport_map'
:(.init.text+0x4830): undefined reference to `ioport_unmap'

This changes the Kconfig logic to take that option away and
always force building the platform variant of this driver if
CONFIG_HAS_IOPORT_MAP is not set. This is the only correct
choice in this case, and it avoids the build error.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/cirrus/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cirrus/Kconfig 
b/drivers/net/ethernet/cirrus/Kconfig
index 7403dff8f14a..905ac5f5d9a6 100644
--- a/drivers/net/ethernet/cirrus/Kconfig
+++ b/drivers/net/ethernet/cirrus/Kconfig
@@ -32,7 +32,8 @@ config CS89x0
  will be called cs89x0.
 
 config CS89x0_PLATFORM
-   bool "CS89x0 platform driver support"
+   bool "CS89x0 platform driver support" if HAS_IOPORT_MAP
+   default !HAS_IOPORT_MAP
depends on CS89x0
help
  Say Y to compile the cs89x0 driver as a platform driver. This
-- 
2.1.0.rc2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 3/4] net: lance,ni64: don't build for ARM

2015-01-28 Thread Arnd Bergmann 
The ni65 and lance ethernet drivers manually program the ISA DMA
controller that is only available on x86 PCs and a few compatible
systems. Trying to build it on ARM results in this error:

ni65.c: In function 'ni65_probe1':
ni65.c:496:62: error: 'DMA1_STAT_REG' undeclared (first use in this function)
 ((inb(DMA1_STAT_REG) >> 4) & 0x0f)
  ^
ni65.c:496:62: note: each undeclared identifier is reported only once for each 
function it appears in
ni65.c:497:63: error: 'DMA2_STAT_REG' undeclared (first use in this function)
 | (inb(DMA2_STAT_REG) & 0xf0);

The DMA1_STAT_REG and DMA2_STAT_REG registers are only defined for
alpha, mips, parisc, powerpc and x86, although it is not clear
which subarchitectures actually have them at the correct location.

This patch for now just disables it for ARM, to avoid randconfig
build errors. We could also decide to limit it to the set of
architectures on which it does compile, but that might look more
deliberate than guessing based on where the drivers build.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/amd/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 5d3b5202327c..c638c85f3954 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -45,7 +45,7 @@ config AMD8111_ETH
 
 config LANCE
tristate "AMD LANCE and PCnet (AT1500 and NE2100) support"
-   depends on ISA && ISA_DMA_API
+   depends on ISA && ISA_DMA_API && !ARM
---help---
  If you have a network (Ethernet) card of this type, say Y and read
  the Ethernet-HOWTO, available from
@@ -142,7 +142,7 @@ config PCMCIA_NMCLAN
 
 config NI65
tristate "NI6510 support"
-   depends on ISA && ISA_DMA_API
+   depends on ISA && ISA_DMA_API && !ARM
---help---
  If you have a network (Ethernet) card of this type, say Y and read
  the Ethernet-HOWTO, available from
-- 
2.1.0.rc2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH] pcmcia: add missing include for new pci resource handler

2015-01-13 Thread Arnd Bergmann 
The recently added rsrc_pci.c file calls pci_bus_alloc_resource without
including the header file that declares it, and that sometimes causes
a build warning on ARM:

drivers/pcmcia/rsrc_pci.c: In function 'find_io_region':
drivers/pcmcia/rsrc_pci.c:40:2: error: implicit declaration of function 
'pci_bus_alloc_resource' [-Werror=implicit-function-declaration]

This adds the missing include statement.

Signed-off-by: Arnd Bergmann 
Cc: Alan Cox 
Cc: Greg Kroah-Hartman 
Fixes: 02b03846bb2be ("pcmcia: add a new resource manager for non ISA systems")
---
diff --git a/drivers/pcmcia/rsrc_pci.c b/drivers/pcmcia/rsrc_pci.c
index 8934d3c01f80..21c3683b1a53 100644
--- a/drivers/pcmcia/rsrc_pci.c
+++ b/drivers/pcmcia/rsrc_pci.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH 1/2] net/am2150: fix nmclan_cs.c shared interrupt handling

2014-11-24 Thread Arnd Bergmann 
On Friday 21 November 2014 15:17:35 David Miller wrote:
> From: Arnd Bergmann 
> Date: Thu, 20 Nov 2014 16:11:14 +0100
> 
> > A recent patch tried to work around a valid warning for the use of a
> > deprecated interface by blindly changing from the old
> > pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().
> > 
> > This driver has an interrupt handler that is not currently aware
> > of shared interrupts, but can be easily converted to be.
> > At the moment, the driver reads the interrupt status register
> > repeatedly until it contains only zeroes in the interesting bits,
> > and handles each bit individually.
> > 
> > This patch adds the missing part of returning IRQ_NONE in case none
> > of the bits are set to start with, so we can move on to the next
> > interrupt source.
> > 
> > Signed-off-by: Arnd Bergmann 
> > Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA 
> > API")
> > ---
> > I had this patch in my queue of things to submit and noticed that
> > the warning had gone away upstream but my patch was still there.
> > 
> > For all I can tell, the driver is broken without this, although it
> > would rarely be a problem.
> 
> I'm happy for this to go alongside patch #2 via another tree:
> 
> Acked-by: David S. Miller 

I was hoping you could take at least this one, possibly both.
Since you already had Jeff's patch in it, the first patch now
fixes a (mostly harmless) 3.18 regression, and the second patch
is just a cosmetic cleanup, but there is no longer any dependency
between the two.

It looks like Greg is now handling most of the PCMCIA patches
in the absence of a subsystem maintainer, so I'll send him the
second one for 3.19, let me know if you still want me to send
him the first one too.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 2/2] pcmcia: remove pcmcia_request_exclusive_irq

2014-11-20 Thread Arnd Bergmann 
The last user of the deprecated pcmcia_request_exclusive_irq function,
was removed in 5f5316fcd08e ("am2150: Update nmclan_cs.c to use update
PCMCIA API"), so we can clean up the core code and remove the interface
and its documentation.

Signed-off-by: Arnd Bergmann 
---
 Documentation/pcmcia/driver-changes.txt |  3 ---
 drivers/pcmcia/pcmcia_resource.c| 39 
---
 include/pcmcia/ds.h | 10 --
 3 files changed, 0 insertions(+), 52 deletions(-)

---
The patch that removed the last user was merged in 3.18-rc1, so this
should be safe to apply independently now.

diff --git a/Documentation/pcmcia/driver-changes.txt 
b/Documentation/pcmcia/driver-changes.txt
index dd04361dd361..78355c4c268a 100644
--- a/Documentation/pcmcia/driver-changes.txt
+++ b/Documentation/pcmcia/driver-changes.txt
@@ -46,9 +46,6 @@ This file details changes in 2.6 which affect PCMCIA card 
driver authors:
- use pcmcia_request_irq(p_dev, handler_t); the PCMCIA core will
  clean up automatically on calls to pcmcia_disable_device() or
  device ejection.
-   - drivers still not capable of IRQF_SHARED (or not telling us so) may
- use the deprecated pcmcia_request_exclusive_irq() for the time
- being; they might receive a shared IRQ nonetheless.
 
 * no cs_error / CS_CHECK / CONFIG_PCMCIA_DEBUG (as of 2.6.33)
Instead of the cs_error() callback or the CS_CHECK() macro, please use
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index e8c19def1b0f..23a123da3dd7 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -712,45 +712,6 @@ int __must_check pcmcia_request_irq(struct pcmcia_device 
*p_dev,
 }
 EXPORT_SYMBOL(pcmcia_request_irq);
 
-
-/**
- * pcmcia_request_exclusive_irq() - attempt to request an exclusive IRQ first
- * @p_dev: the associated PCMCIA device
- * @handler: IRQ handler to register
- *
- * pcmcia_request_exclusive_irq() is a wrapper around request_irq() which
- * attempts first to request an exclusive IRQ. If it fails, it also accepts
- * a shared IRQ, but prints out a warning. PCMCIA drivers should allow for
- * IRQ sharing and either use request_irq directly (then they need to call
- * free_irq() themselves, too), or the pcmcia_request_irq() function.
- */
-int __must_check
-__pcmcia_request_exclusive_irq(struct pcmcia_device *p_dev,
-   irq_handler_t handler)
-{
-   int ret;
-
-   if (!p_dev->irq)
-   return -EINVAL;
-
-   ret = request_irq(p_dev->irq, handler, 0, p_dev->devname, p_dev->priv);
-   if (ret) {
-   ret = pcmcia_request_irq(p_dev, handler);
-   dev_printk(KERN_WARNING, &p_dev->dev, "pcmcia: "
-   "request for exclusive IRQ could not be fulfilled.\n");
-   dev_printk(KERN_WARNING, &p_dev->dev, "pcmcia: the driver "
-   "needs updating to supported shared IRQ lines.\n");
-   }
-   if (ret)
-   dev_printk(KERN_INFO, &p_dev->dev, "request_irq() failed\n");
-   else
-   p_dev->_irq = 1;
-
-   return ret;
-} /* pcmcia_request_exclusive_irq */
-EXPORT_SYMBOL(__pcmcia_request_exclusive_irq);
-
-
 #ifdef CONFIG_PCMCIA_PROBE
 
 /* mask of IRQs already reserved by other cards, we should avoid using them */
diff --git a/include/pcmcia/ds.h b/include/pcmcia/ds.h
index 2d56e428506c..3037157855f0 100644
--- a/include/pcmcia/ds.h
+++ b/include/pcmcia/ds.h
@@ -206,16 +206,6 @@ int pcmcia_write_config_byte(struct pcmcia_device *p_dev, 
off_t where, u8 val);
 /* device configuration */
 int pcmcia_request_io(struct pcmcia_device *p_dev);
 
-int __must_check
-__pcmcia_request_exclusive_irq(struct pcmcia_device *p_dev,
-   irq_handler_t handler);
-static inline __must_check __deprecated int
-pcmcia_request_exclusive_irq(struct pcmcia_device *p_dev,
-   irq_handler_t handler)
-{
-   return __pcmcia_request_exclusive_irq(p_dev, handler);
-}
-
 int __must_check pcmcia_request_irq(struct pcmcia_device *p_dev,
irq_handler_t handler);
 


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 1/2] net/am2150: fix nmclan_cs.c shared interrupt handling

2014-11-20 Thread Arnd Bergmann 
A recent patch tried to work around a valid warning for the use of a
deprecated interface by blindly changing from the old
pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().

This driver has an interrupt handler that is not currently aware
of shared interrupts, but can be easily converted to be.
At the moment, the driver reads the interrupt status register
repeatedly until it contains only zeroes in the interesting bits,
and handles each bit individually.

This patch adds the missing part of returning IRQ_NONE in case none
of the bits are set to start with, so we can move on to the next
interrupt source.

Signed-off-by: Arnd Bergmann 
Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA API")
---
I had this patch in my queue of things to submit and noticed that
the warning had gone away upstream but my patch was still there.

For all I can tell, the driver is broken without this, although it
would rarely be a problem.

diff --git a/drivers/net/ethernet/amd/nmclan_cs.c 
b/drivers/net/ethernet/amd/nmclan_cs.c
index 5b22764ba88d..27245efe9f50 100644
--- a/drivers/net/ethernet/amd/nmclan_cs.c
+++ b/drivers/net/ethernet/amd/nmclan_cs.c
@@ -952,6 +952,8 @@ static irqreturn_t mace_interrupt(int irq, void *dev_id)
   do {
 /* WARNING: MACE_IR is a READ/CLEAR port! */
 status = inb(ioaddr + AM2150_MACE_BASE + MACE_IR);
+if (!(status & ~MACE_IMR_DEFAULT) && IntrCnt == MACE_MAX_IR_ITERATIONS)
+  return IRQ_NONE;
 
 pr_debug("mace_interrupt: irq 0x%X status 0x%X.\n", irq, status);
 


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 2/3] pcmcia: pxa2xx: fix logic for lubbock

2014-06-05 Thread Arnd Bergmann 
The lubbock platform uses the sa companion chip with a pxa250
CPU, which means it requires both the PCMCIA_SA and the
PCMCIA_PXA2XX code to be built into the kernel. Unfortunately,
the Makefile and Kconfig don't agree on how this is accomplished,
leading to a situation where you get this link error when building
a lubbock kernel with PCMCIA_SA enabled but PCMCIA_PXA2XX
disabled:

ERROR: "pxa2xx_configure_sockets" [drivers/pcmcia/sa_cs.ko] undefined!
ERROR: "pxa2xx_drv_pcmcia_ops" [drivers/pcmcia/sa_cs.ko] undefined!
ERROR: "pxa2xx_drv_pcmcia_add_one" [drivers/pcmcia/sa_cs.ko] undefined!

This patch changes the Kconfig code to disallow that particular
configuration.

Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 0c657d6..51cf808 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -202,6 +202,7 @@ config PCMCIA_SA
depends on ARM && SA && PCMCIA
select PCMCIA_SOC_COMMON
select PCMCIA_SA11XX_BASE if ARCH_SA1100
+   select PCMCIA_PXA2XX if ARCH_LUBBOCK && SA
help
  Say Y  here to include support for SA-based PCMCIA or CF
  sockets, found on the Jornada 720, Graphicsmaster and other
@@ -217,7 +218,6 @@ config PCMCIA_PXA2XX
|| ARCOM_PCMCIA || ARCH_PXA_ESERIES || MACH_STARGATE2 \
|| MACH_VPAC270 || MACH_BALLOON3 || MACH_COLIBRI \
|| MACH_COLIBRI320 || MACH_H4700)
-   select PCMCIA_SA if ARCH_LUBBOCK && SA
select PCMCIA_SOC_COMMON
help
  Say Y here to include support for the PXA2xx PCMCIA controller
-- 
1.8.3.2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 1/3] pcmcia: journada720: use sa1100 pin interfaces correctly

2014-06-05 Thread Arnd Bergmann 
commit dabd14684bc2 "PCMCIA: sa: remove duplicated initializers"
incorrectly moved some code into the pcmcia_jornada720_init, causing
a few build errors, and for unknown reasons, the driver lacks
an inclusion of , so we get the build errors, and more:

sa_jornada720.c: In function 'pcmcia_jornada720_init':
sa_jornada720.c:101:3: error: implicit declaration of function 'IOMEM' 
[-Werror=implicit-function-declaration]
   GRER |= 0x0002;
   ^
sa_jornada720.c:104:3: warning: passing argument 1 of 'sa_set_io_dir' 
from incompatible pointer type [enabled by default]
   sa_set_io_dir(dev, pin, 0, 0);
   ^

This patch uses the SA_DEV() to convert the dev pointer to the
correct type before passing it and adds the missing include.

Signed-off-by: Arnd Bergmann 
Cc: Russell King 
Cc: Kristoffer Ericson 
Cc: linux-pcmcia@lists.infradead.org
---
 drivers/pcmcia/sa_jornada720.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/pcmcia/sa_jornada720.c 
b/drivers/pcmcia/sa_jornada720.c
index 3baa3ef..40e0403 100644
--- a/drivers/pcmcia/sa_jornada720.c
+++ b/drivers/pcmcia/sa_jornada720.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -94,6 +95,7 @@ static struct pcmcia_low_level jornada720_pcmcia_ops = {
 int pcmcia_jornada720_init(struct device *dev)
 {
int ret = -ENODEV;
+   struct sa_dev *sadev = SA_DEV(dev);
 
if (machine_is_jornada720()) {
unsigned int pin = GPIO_A0 | GPIO_A1 | GPIO_A2 | GPIO_A3;
@@ -101,12 +103,12 @@ int pcmcia_jornada720_init(struct device *dev)
GRER |= 0x0002;
 
/* Set GPIO_A<3:1> to be outputs for PCMCIA/CF power 
controller: */
-   sa_set_io_dir(dev, pin, 0, 0);
-   sa_set_io(dev, pin, 0);
-   sa_set_sleep_io(dev, pin, 0);
+   sa_set_io_dir(sadev, pin, 0, 0);
+   sa_set_io(sadev, pin, 0);
+   sa_set_sleep_io(sadev, pin, 0);
 
sa11xx_drv_pcmcia_ops(&jornada720_pcmcia_ops);
-   ret = sa_pcmcia_add(dev, &jornada720_pcmcia_ops,
+   ret = sa_pcmcia_add(sadev, &jornada720_pcmcia_ops,
sa11xx_drv_pcmcia_add_one);
}
 
-- 
1.8.3.2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 3/3] pcmcia: sa1100: H3100 and H3600 share a driver

2014-06-05 Thread Arnd Bergmann 
When building a iPAQ H3100-only kernel with PCMCIA enabled,
we get this build error:

ERROR: "pcmcia_h3600_init" [drivers/pcmcia/sa1100_cs.ko] undefined!

The defconfig normally works fine because it enables both H3100
and H3600 support. This patch fixes the Makefile to build the
driver if at least one of the two machines are selected.

Signed-off-by: Arnd Bergmann 
---
 drivers/pcmcia/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pcmcia/Makefile b/drivers/pcmcia/Makefile
index 7745b51..fd55a69 100644
--- a/drivers/pcmcia/Makefile
+++ b/drivers/pcmcia/Makefile
@@ -49,6 +49,7 @@ sa1100_cs-y   += 
sa1100_generic.o
 sa1100_cs-$(CONFIG_SA1100_ASSABET) += sa1100_assabet.o
 sa1100_cs-$(CONFIG_SA1100_CERF)+= sa1100_cerf.o
 sa1100_cs-$(CONFIG_SA1100_COLLIE)  += pxa2xx_sharpsl.o
+sa1100_cs-$(CONFIG_SA1100_H3100)   += sa1100_h3600.o
 sa1100_cs-$(CONFIG_SA1100_H3600)   += sa1100_h3600.o
 sa1100_cs-$(CONFIG_SA1100_NANOENGINE)  += sa1100_nanoengine.o
 sa1100_cs-$(CONFIG_SA1100_SHANNON) += sa1100_shannon.o
-- 
1.8.3.2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 0/3] pcmcia randconfig fixes

2014-06-05 Thread Arnd Bergmann 
Here are three small bug fixes for ancient build bugs from
my randconfig queue. No urgency here, but I'm unsure who would
pick them up these days, since there doesn't seem to be anyone
left sending pull requests for pcmcia.

Arnd Bergmann (3):
  pcmcia: journada720: use sa1100 pin interfaces correctly
  pcmcia: pxa2xx: fix logic for lubbock
  pcmcia: sa1100: H3100 and H3600 share a driver

 drivers/pcmcia/Kconfig |  2 +-
 drivers/pcmcia/Makefile|  1 +
 drivers/pcmcia/sa_jornada720.c | 10 ++
 3 files changed, 8 insertions(+), 5 deletions(-)

-- 
1.8.3.2


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH v2 0/8] ARM: mostly harmless gcc warnings

2012-10-09 Thread Arnd Bergmann 
Most patches from the first time this was posted have been
adopted by a subsystem maintainer or were show to be obsolete.
Here are the remaining ones again.

I'm planning to submit those patches that are still necessary
by the time we have an -rc1 through the arm-soc tree, but
my preference is still to have them go through the subsystem
maintainers.

Olof: should we add it to for-next?

Arnd

Arnd Bergmann (8):
  SCSI: ARM: ncr5380/oak uses no interrupts
  SCSI: ARM: make fas216_dumpinfo function conditional
  mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
  USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
  clk: don't mark clkdev_add_table as init
  pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
  video: mark nuc900fb_map_video_memory as __devinit
  spi/s3c64xx: use correct dma_transfer_direction type

 drivers/clk/clkdev.c|2 +-
 drivers/pcmcia/pxa2xx_sharpsl.c |2 +-
 drivers/scsi/arm/fas216.c   |2 +-
 drivers/scsi/arm/oak.c  |1 +
 drivers/spi/spi-s3c64xx.c   |2 +-
 drivers/usb/host/ehci-orion.c   |2 +-
 drivers/video/nuc900fb.c|2 +-
 mm/slob.c   |6 +++---
 8 files changed, 10 insertions(+), 9 deletions(-)

-- 
1.7.10

Cc: "James E.J. Bottomley" 
Cc: Ben Dooks 
Cc: Dominik Brodowski 
Cc: Florian Tobias Schandinat 
Cc: Grant Likely 
Cc: Greg Kroah-Hartman 
Cc: Jochen Friedrich 
Cc: Kukjin Kim 
Cc: Mike Turquette 
Cc: Pavel Machek 
Cc: Pekka Enberg 
Cc: Russell King 
Cc: Wan ZongShun 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-pcmcia@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: sta...@vger.kernel.org

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH v2 6/8] pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops

2012-10-09 Thread Arnd Bergmann 
The sharpsl_pcmcia_ops structure gets passed into
sa11xx_drv_pcmcia_probe, where it gets accessed at run-time,
unlike all other pcmcia drivers that pass their structures
into platform_device_add_data, which makes a copy.

This means the gcc warning is valid and the structure
must not be marked as __initdata.

Without this patch, building collie_defconfig results in:

drivers/pcmcia/pxa2xx_sharpsl.c:22:31: fatal error: mach-pxa/hardware.h: No 
such file or directory
compilation terminated.
make[3]: *** [drivers/pcmcia/pxa2xx_sharpsl.o] Error 1
make[2]: *** [drivers/pcmcia] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

Signed-off-by: Arnd Bergmann 
Cc: Dominik Brodowski 
Cc: Russell King 
Cc: Pavel Machek 
Cc: linux-pcmcia@lists.infradead.org
Cc: Jochen Friedrich 
Cc: sta...@vger.kernel.org
---
 drivers/pcmcia/pxa2xx_sharpsl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/pxa2xx_sharpsl.c b/drivers/pcmcia/pxa2xx_sharpsl.c
index b066273..7dd879c 100644
--- a/drivers/pcmcia/pxa2xx_sharpsl.c
+++ b/drivers/pcmcia/pxa2xx_sharpsl.c
@@ -194,7 +194,7 @@ static void sharpsl_pcmcia_socket_suspend(struct 
soc_pcmcia_socket *skt)
sharpsl_pcmcia_init_reset(skt);
 }
 
-static struct pcmcia_low_level sharpsl_pcmcia_ops __initdata = {
+static struct pcmcia_low_level sharpsl_pcmcia_ops = {
.owner  = THIS_MODULE,
.hw_init= sharpsl_pcmcia_hw_init,
.socket_state   = sharpsl_pcmcia_socket_state,
-- 
1.7.10


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

[PATCH 11/16] pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops

2012-10-05 Thread Arnd Bergmann 
The sharpsl_pcmcia_ops structure gets passed into
sa11xx_drv_pcmcia_probe, where it gets accessed at run-time,
unlike all other pcmcia drivers that pass their structures
into platform_device_add_data, which makes a copy.

This means the gcc warning is valid and the structure
must not be marked as __initdata.

Signed-off-by: Arnd Bergmann 
Cc: Dominik Brodowski 
Cc: Russell King 
Cc: Pavel Machek 
Cc: linux-pcmcia@lists.infradead.org
Cc: Jochen Friedrich 
Cc: sta...@vger.kernel.org
---
 drivers/pcmcia/pxa2xx_sharpsl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/pxa2xx_sharpsl.c b/drivers/pcmcia/pxa2xx_sharpsl.c
index b066273..7dd879c 100644
--- a/drivers/pcmcia/pxa2xx_sharpsl.c
+++ b/drivers/pcmcia/pxa2xx_sharpsl.c
@@ -194,7 +194,7 @@ static void sharpsl_pcmcia_socket_suspend(struct 
soc_pcmcia_socket *skt)
sharpsl_pcmcia_init_reset(skt);
 }
 
-static struct pcmcia_low_level sharpsl_pcmcia_ops __initdata = {
+static struct pcmcia_low_level sharpsl_pcmcia_ops = {
.owner  = THIS_MODULE,
.hw_init= sharpsl_pcmcia_hw_init,
.socket_state   = sharpsl_pcmcia_socket_state,
-- 
1.7.10


___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] spi: reorganize drivers

2011-06-06 Thread Arnd Bergmann 
On Monday 06 June 2011, Stefan Richter wrote:
> On Jun 06 Arnd Bergmann wrote:
> > On Monday 06 June 2011, Jean Delvare wrote:
> On drivers/firewire/:
> 
> FireWire drivers are currently spread over drivers/firewire (three
> link-layer controller drivers + the IEEE 1394 core + two IEEE 1394
> application layer drivers), drivers/media/dvb/firewire/ (one 1394
> application layer driver), sound/firewire/ (two 1394 application layer
> drivers, more are planned to be added there).
> 
> From the Linux driver model POV,
>   1. the IEEE 1394 core driver implements the firewire bus,
>   2. the link-layer controller drivers implement pci bus based devices,
>   3. the IEEE 1394 application layer drivers implement firewire bus based
>  devices.  The two of them that are located in drivers/firewire/
>  expose a SCSI LLD (a transport in SCSI Architecture Model terms, but
>  a host rather than a transport in Linux implementation terms) and a
>  networking interface driver.
> 
> Number 2 is something one would expect to find in a hypothetical
> drivers/bus/ directory.  But where do the others belong?
> 
> Would type 1 drivers be kept in drivers/bus/firewire/?  I understand your
> above response to Jean that this is what you have in mind.

Correct.

> firewire-sbp2 could be moved into drivers/scsi/, and firewire-net could be
> moved into drivers/net/.  But what about maintenance?  They could still be
> maintained via linux1394-2.6.git because this worked so far, but then the
> directory structure might irritate people who don't use
> scripts/get_maintainer.pl all the time.  Well, I could actually picture
> firewire-net to be maintained via the net development tree, but I do
> wonder how well firewire-sbp2 maintenance through the scsi tree would work.

I guess the real question is whether firewire should be considered a bus
like USB or a device class like SCSI, and it's abit of a grey area (SCSI
is too). If you declare it to be a bus, I'd suggest moving the sbp2 and
network drivers to drivers/scsi and drivers/net. If you like to think
of firewire as a closed subsystem instead, it's probably better to leave
all of it in drivers/firewire.

> PS,
> these are the same questions like with USB, only on a smaller scale.  (The
> usb-storage driver is maintained through the usb tree as well, not the
> scsi tree.  drivers/net/usb/ has got T: git .../gregkh/usb-2.6.git
> assigned in MAINTAINERS but most of the commits there are actually done by
> DaveM.)

The difference that I see with usb-storage is that this one is really
a set of different drivers for all sorts of devices, while the firewire sbp2
driver feels more like a single driver that includes a few special
cases. Also, USB is generally perceived as a generic interconnect, while
firewire is seen primarily as a way to attach disk drives.

The differences are of course gradual.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] spi: reorganize drivers

2011-06-06 Thread Arnd Bergmann 
On Monday 06 June 2011, Jean Delvare wrote:
> On Mon, 6 Jun 2011 13:21:07 +0200, Arnd Bergmann wrote:
> > A top-level /bus would work for me, and I guess would also address Russell's
> > concern. Regarding bus-specific drivers, we're gradually moving those out
> > of the bus specific directories anyway, basically the only bus directory
> > that really has device driver in it is USB at this point. It makes some
> > sense to have a bus-specific low-level user space interface driver like
> > sg or uio in the bus directory, but everything else should really belong
> > into some other subsystem.
> 
> Err, what about I2C and SPI? Aren't drivers/i2c/busses and drivers/spi
> full of "device drivers"? Or are these what you call "bus-specific
> drivers"? Maybe we need to define all the terms before the discussion
> continues further.

drivers/i2c/busses and drivers/spi are full of what I would call "bus
drivers" or "host drivers". They bind to a device from another bus
(platform, pci, ...) and export devices of their own type (i2c, spi, ...).
This is what all bus drivers do.

An i2c or spi device driver would in turn bind to that device and
provide a functionality not specific to that bus (e.g. hwmon, input,
leds, rtc or media).

> > (...)
> > This is about to get worse as we introduce new subsystems (e.g. iommu,
> > irq, clocksource, eeprom, nvram, ...) into which we are moving
> > code from arch/arm, drivers/char and drivers/misc. Having buses and
> > drivers in a separate hierarchy would make the drivers directory and
> > the respective menuconfig list more clearly structured IMHO.
> 
> This gets interesting. Would you suggest for example that i2c-core.c
> goes to bus/i2c, and drivers/i2c/busses becomes drivers/i2c? And that
> CONFIG_I2C is somewhere in menuconfig, and the hardware driver
> selection for drivers/i2c is in a totally different place?

No, all of drivers/i2c would go into bus/i2c or drivers/bus/i2c, there
is no point splitting that. The part that would no go there is the various
drivers that are already not under drivers/i2c but are for devices
connected to an i2c bus.

The confusion is probably that in case of drivers/scsi and drivers/usb,
both bus and device drivers are in the same subdirectories. If we move
drivers/usb to bus/usb, I would probably recommend to split
drivers/usb/{serial,storage,atm,misc} out of it and move it to
drivers/{tty/usb-serial,block/usb,net/usb/atm,misc/usb} though, to
make it look more like PCI or i2c that already have a clean split.

> While I am surprised, I am not necessarily objecting. But it seems that
> you should better define what your actual plan is, before asking us if
> we agree with it.

My original plan was to think this through a bit more, but Grant posted
the big spi reorganization, so I jumped in on that because it wouldn't
be nice to have to move all those drivers again.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] spi: reorganize drivers

2011-06-06 Thread Arnd Bergmann 
On Monday 06 June 2011, James Bottomley wrote:
> I'd say it only makes sense if we do it for all busses ... so USB and
> PCI would have to move too.  Logically, the bus code should move and we
> should be left with the drivers in both of those directories.  I'd also
> say that we don't have to deepen the tree: /bus would be fine.  That
> way, /drivers/ would be only for  specific drivers, with non
> bus specific drivers we just group them by function as now.

A top-level /bus would work for me, and I guess would also address Russell's
concern. Regarding bus-specific drivers, we're gradually moving those out
of the bus specific directories anyway, basically the only bus directory
that really has device driver in it is USB at this point. It makes some
sense to have a bus-specific low-level user space interface driver like
sg or uio in the bus directory, but everything else should really belong
into some other subsystem.

> What about the half busses (like SCSI)?

I think SCSI is a really special case, not just because of its size
of more than twice the code than everything else I would suggest to
move, but also because it contains mostly host drivers but very few
device drivers (sd, sr, osst, st, and sg). In that sense it's more
a class of devices than a bus and fits in the same category as
mmc and ata than a bus like pci or i2c that have a multitude of
device drivers.

> Finally, is there any real point (other than we can do it)?  what is
> actually helped by having the bus code obviously separated from the
> driver code (assuming we sort out what is bus and what is driver)?

Mostly I think the drivers/ subdirectory is getting a bit cluttered with
stuff that doesn't really fit together, and bus drivers are typically
directories with less than five files in them, apart from the few
exceptions that already came up.

This is about to get worse as we introduce new subsystems (e.g. iommu,
irq, clocksource, eeprom, nvram, ...) into which we are moving
code from arch/arm, drivers/char and drivers/misc. Having buses and
drivers in a separate hierarchy would make the drivers directory and
the respective menuconfig list more clearly structured IMHO.

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] spi: reorganize drivers

2011-06-06 Thread Arnd Bergmann 
On Sunday 05 June 2011, Grant Likely wrote:
>  rename drivers/spi/{omap2_mcspi.c => spi_omap2_mcspi.c} (100%)
>  rename drivers/spi/{omap_spi_100k.c => spi_omap_100k.c} (100%)
>  rename drivers/spi/{omap_uwire.c => spi_omap_uwire.c} (100%)
>  rename drivers/spi/{orion_spi.c => spi_orion.c} (100%)
>  rename drivers/spi/{amba-pl022.c => spi_pl022.c} (100%)
>  rename drivers/spi/{pxa2xx_spi.c => spi_pxa2xx.c} (100%)
>  rename drivers/spi/{pxa2xx_spi_pci.c => spi_pxa2xx_pci.c} (100%)
>  rename drivers/spi/{ti-ssp-spi.c => spi_ti_ssp.c} (100%)
>  rename drivers/spi/{tle62x0.c => spi_tle62x0.c} (100%)
>  rename drivers/spi/{xilinx_spi.c => spi_xilinx.c} (100%)

I recently looked at the directory structure in drivers/ and found a lot
of bus drivers with very few files, plus a few bus drivers with a lot
of files in them besides directories for non-bus specific subsystems.

I think it would be good to move them into a deeper directory drivers/bus/
if we have support from the maintainers, and it's probably better if we
only have to move the files once to reduce the amount of churn on the
MAINTAINERS file and any out of tree patches.

Specifically, I'd like to do these moves:

drivers/{ => bus}/amba
drivers/{ => bus}/dio
drivers/{ => bus}/eisa
drivers/{ => bus}/firewire
drivers/{ => bus}/i2c
drivers/{ => bus}/mca
drivers/{ => bus}/nubus
drivers/{ => bus}/pcmcia
drivers/{ => bus}/rapidio
drivers/{ => bus}/sbus
drivers/{ => bus}/spi
drivers/{ => bus}/ssb
drivers/{ => bus}/tc
drivers/{ => bus}/uwb
drivers/{ => bus}/virtio
drivers/{ => bus}/vlync
drivers/{ => bus}/w1
drivers/{ => bus}/zorro

This leaves out the two most common buses, USB and PCI, mostly because
the directories contain a lot of stuff that is not really bus code
but actual drivers. It does include i2c and spi, which stick out by
being a lot larger than most others.

Opinions? Move or don't move?

Arnd

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

2007-06-24 Thread Arnd Bergmann 
On Monday 25 June 2007, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
> 
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.

I just realized that this argument is bogus, because the user space tools
are probably, or at least potentially, built as 32 bit binaries, which
means that any interface using these _will_ break.

However, I could not find any actual user space interfaces in 2.6.22-rc
that are built around ioaddr_t. What are they, or have the been removed
by now?

Arnd <><

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] pasemi: Electra CF driver

2007-05-15 Thread Arnd Bergmann 
On Tuesday 15 May 2007, Olof Johansson wrote:
> Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
> a simple device sitting on localbus, with interrupts and detect/voltage
> control over GPIO.

The driver looks really good, there is nothing for me to complain about.

> The driver is implemented as an of_platform driver, and adds localbus
> as a bus being probed by the of_platform framework.

I supposed "localbus" is what the current firmware ships with in the
device tree, right? If you still have the choice on how this is
represented it might be better not to invent another device-type
but rather make this "soc" or whatever existing type we know about.

Arnd <><

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support

2007-05-03 Thread Arnd Bergmann 
On Friday 04 May 2007, Vitaly Bordug wrote:
> Adds support for PowerQuicc on-chip PCMCIA. The driver is implemented as
> of_device, so only arch/powerpc stuff is capable to use it, which now
> implies only mpc885ads reference board.
> 
> To cope with the code that should be hooked inside driver, but is really
> board specific (like set_voltage), global structure mpc8xx_pcmcia_ops
> holds necessary function pointers that are filled in the BSP code.
> 
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> 

Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support

2007-05-03 Thread Arnd Bergmann 
On Thursday 03 May 2007, Segher Boessenkool wrote:
> > For example, you could make this
> >
> >   compatible = "8xx\0mpc885ads";
> 
> "mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that.

Right. I can never remember what goes first...

Arnd <><

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support

2007-05-03 Thread Arnd Bergmann 
On Thursday 03 May 2007, Vitaly Bordug wrote:

> Adds support for PowerQuicc on-chip PCMCIA. The driver is implemented as
> of_device, so only arch/powerpc stuff is capable to use it, which now
> implies only mpc885ads reference board.

Very nice, looks much better now than the previous version.

> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts 
> b/arch/powerpc/boot/dts/mpc885ads.dts
> index 110bf61..89d585f 100644
> --- a/arch/powerpc/boot/dts/mpc885ads.dts
> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
> @@ -112,6 +112,18 @@
>   compatible = "CPM";
>   };
>  
> +   [EMAIL PROTECTED] {
> +   linux,phandle = <0080>;
> +   #interrupt-cells = <1>;
> +   #size-cells = <2>;
> +   compatible = "8xx";
> +   device_type = "pcmcia";
> +   reg = <80 80>;
> +   clock-frequency = <2faf080>;
> +   interrupt-parent = ;
> +   interrupts = ;
> + };
> +
>   [EMAIL PROTECTED] {
>   linux,phandle = ;
>   #address-cells = <1>;

The compatible property should be a little more specific, imho. Since there
are differences in how things are done depending on the board, it would be
good to tell the exact method from the pcmcia node itself.

For example, you could make this

compatible = "8xx\0mpc885ads";

Your code doesn't currently use this, I like to have the option.

> +#ifdef CONFIG_PCMCIA_M8XX
> +static void pcmcia_hw_setup(int slot, int enable);
> +static int pcmcia_set_voltage(int slot, int vcc, int vpp);
> +
> +struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops = {
> + .hw_ctrl = pcmcia_hw_setup,
> + .voltage_set = pcmcia_set_voltage,
> +};
> +#endif
> +
>  void __init mpc885ads_board_setup(void)
>  {
>   cpm8xx_t *cp;

If you define the global variable in the board code, you can not have multiple
board implementations in a multiplatform kernel.
In order to make that work, you'd need to have the definition of m8xx_pcmcia_ops
in 8xx common code, and then assign the two function pointers dynamically in the
board initialization.

> + if (of_address_to_resource(np, 0, &r))
> + return -EINVAL;
> +
> + pcmcia = ioremap(r.start, r.end - r.start + 1);
> + if(pcmcia == NULL)
> + return -EINVAL;

A new of_iomap() function was recently added that allows you
to do these two steps in one.

> -/* connect interrupt and disable CxOE */
> + out_be32(M8XX_PGCRX(0), M8XX_PGCRX_CXOE | (mk_int_int_mask(hwirq) << 
> 16));
> + out_be32(M8XX_PGCRX(1), M8XX_PGCRX_CXOE | (mk_int_int_mask(hwirq) << 
> 16));

I'm not sure why you need to use the hwirq here, it should not be visible to
device drivers normally.

Is this the same as enable_irq(pcmcia_schlvl) ?

Arnd <><

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia

Re: Fw: [PATCH][RFC] PCMCIA support for 8xx using platform devices

2007-04-22 Thread Arnd Bergmann 
On Sunday 22 April 2007, Vitaly Bordug wrote:
> This utilizes PCMCIA on mpc885ads and mpc866ads from arch/powerpc. In the
> new approach, direct IMMR accesses from within drivers/ were totally
> eliminated, that requires hardware_enable, hardware_disable, voltage_set
> board-specific functions to be moved over to BSP code section   
> (arch/powerpc/platforms/8xx in 885 case). There is just no way to have
> both arch/ppc and arch/powerpc approaches to work simultaneously because
> of that.  

Maybe I'm missing a key issue here, but what's the point of adding
more platform_devices for stuff that is already in the device tree?
Shouldn't this be made an of_platform_driver instead so you can
use the existing of_device directly?

Arnd <><

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia