Add modules to support realtek PCIE card reader

From: Wei WANG <[email protected]>

Realtek PCI-E card reader driver adapts requests from upper-level sdmmc/memstick layer to the real physical card reader.

Signed-off-by Wei WANG <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Tested-by Borislav Petkov <[email protected]>

---
 drivers/mfd/Kconfig             |    9 +
 drivers/mfd/Makefile            |    4 +
 drivers/mfd/rts5209.c           |  188 ++++++
 drivers/mfd/rts5229.c           |  179 ++++++
 drivers/mfd/rtsx_pcr.c          | 1345 +++++++++++++++++++++++++++++++++++++++
 drivers/mfd/rtsx_pcr.h          |   31 +
 include/linux/mfd/rtsx_common.h |   47 ++
 include/linux/mfd/rtsx_pci.h    |  773 ++++++++++++++++++++++
 8 files changed, 2576 insertions(+)
 create mode 100644 drivers/mfd/rts5209.c
 create mode 100644 drivers/mfd/rts5229.c
 create mode 100644 drivers/mfd/rtsx_pcr.c
 create mode 100644 drivers/mfd/rtsx_pcr.h
 create mode 100644 include/linux/mfd/rtsx_common.h
 create mode 100644 include/linux/mfd/rtsx_pci.h

drivers/mfd/Kconfig +0 -0

index d1facef..4c07a34 100644

drivers/mfd/rts5209.c new file +23 -0

new file mode 100644
index 0000000..6680d6d
@@ -0,0 +1,188 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * Author:
+ *   Wei WANG <[email protected]>
+ *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
+ */
+
+#include <linux/module.h>

drivers/mfd/rts5209.c new file +16 -0

+static struct platform_device *rtsx_pci_create_subdev(struct rtsx_pcr *pcr,
+		const char *name, int slot_id)
+{
+	struct platform_device *p_dev;
+	int err;
+
+	p_dev = platform_device_alloc(name, pcr->id);
+	if (p_dev == NULL) {
+		dev_dbg(&(pcr->pci->dev), "alloc platform device fail!\n");
+		return NULL;
+	}
+
+	p_dev->dev.parent = &(pcr->pci->dev);
+	platform_set_drvdata(p_dev, pcr);
+	pcr->slots[slot_id].p_dev = p_dev;
+

drivers/mfd/rts5209.c new file +35 -0

+static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
+{
+	struct rtsx_pcr *pcr = dev_id;
+	u32 int_reg;
+
+	if (!pcr)
+		return IRQ_NONE;
+
+	spin_lock(&pcr->lock);
+
+	int_reg = rtsx_pci_readl(pcr, RTSX_BIPR);
+	/* Clear interrupt flag */
+	rtsx_pci_writel(pcr, RTSX_BIPR, int_reg);
+	if ((int_reg & pcr->bier) == 0) {
+		spin_unlock(&pcr->lock);
+		return IRQ_NONE;
+	}
+	if (int_reg == 0xFFFFFFFF) {
+		spin_unlock(&pcr->lock);
+		return IRQ_HANDLED;
+	}
+
+	int_reg &= (pcr->bier | 0x7FFFFF);
+
+	if (int_reg & SD_INT) {
+		if (int_reg & SD_EXIST) {
+			pcr->need_reset |= SD_EXIST;
+		} else {
+			pcr->need_release |= SD_EXIST;
+			pcr->need_reset &= ~SD_EXIST;
+		}
+	}
+
+	if (int_reg & MS_INT) {
+		if (int_reg & MS_EXIST) {

Hi Wei,

On Tue, Sep 11, 2012 at 12:54:22PM +0800, [email protected] wrote:
Although pretty big, the patch looks mostly good to me.
I only have a few comments:

Quoted 8 lines

drivers/mfd/Kconfig +0 -0

index d1facef..4c07a34 100644
@@ -63,6 +63,15 @@ config MFD_SM501_GPIO
 	 lines on the SM501. The platform data is used to supply the
 	 base number for the first GPIO line to register.
 

drivers/mfd/Kconfig config MFD_SM501_GPIO · line 71

Quoted 6 lines

drivers/mfd/Kconfig +6 -0

+config MFD_RTSX_PCI
+	tristate "Support for Realtek PCI-E driver-based card reader"
+	depends on PCI
+	help
+	  This supports for Realtek PCI-Express driver-based card reader including
+	  rts5209, rts5229, etc. Realtek driver-based card reader supports access

driver-based ?

drivers/mfd/Kconfig config MFD_SM501_GPIO

Quoted 8 lines

drivers/mfd/Kconfig +7 -0

+
+static u8 rts5209_get_ic_version(struct rtsx_pcr *pcr)
+{
+	u8 val;
+
+	val = rtsx_pci_readb(pcr, 0x1C);
+	return val & 0x0F;

For your IO accesses, it would e worth looking at the regmap MMIO routines. It would also simplify your main probe routine.

drivers/mfd/Kconfig

Quoted 4 lines

drivers/mfd/Kconfig +3 -0

+static int rts5209_turn_on_led(struct rtsx_pcr *pcr)
+{
+	return rtsx_pci_write_register(pcr, 0xFD58, 0x01, 0x00);

You have many hardcoded register adresses around this code. Defining them in your header file wouldn't hurt.

Quoted 20 lines

drivers/mfd/Kconfig +19 -0

+static struct platform_device *rtsx_pci_create_subdev(struct rtsx_pcr *pcr,
+		const char *name, int slot_id)
+{
+	struct platform_device *p_dev;
+	int err;
+
+	p_dev = platform_device_alloc(name, pcr->id);
+	if (p_dev == NULL) {
+		dev_dbg(&(pcr->pci->dev), "alloc platform device fail!\n");
+		return NULL;
+	}
+
+	p_dev->dev.parent = &(pcr->pci->dev);
+	platform_set_drvdata(p_dev, pcr);
+	pcr->slots[slot_id].p_dev = p_dev;
+
+	err = platform_device_add(p_dev);
+	if (err) {
+		dev_dbg(&(pcr->pci->dev), "add platform device fail!\n");

drivers/mfd/Kconfig

Quoted 7 lines

drivers/mfd/Kconfig +7 -0

+		pcr->slots[slot_id].p_dev = NULL;
+		platform_device_put(p_dev);
+		return NULL;
+	}
+
+	return p_dev;
+}

Please use the MFD device addition API for that.

Quoted 38 lines

drivers/mfd/Kconfig +38 -0

+static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
+{
+	struct rtsx_pcr *pcr = dev_id;
+	u32 int_reg;
+
+	if (!pcr)
+		return IRQ_NONE;
+
+	spin_lock(&pcr->lock);
+
+	int_reg = rtsx_pci_readl(pcr, RTSX_BIPR);
+	/* Clear interrupt flag */
+	rtsx_pci_writel(pcr, RTSX_BIPR, int_reg);
+	if ((int_reg & pcr->bier) == 0) {
+		spin_unlock(&pcr->lock);
+		return IRQ_NONE;
+	}
+	if (int_reg == 0xFFFFFFFF) {
+		spin_unlock(&pcr->lock);
+		return IRQ_HANDLED;
+	}
+
+	int_reg &= (pcr->bier | 0x7FFFFF);
+
+	if (int_reg & SD_INT) {
+		if (int_reg & SD_EXIST) {
+			pcr->need_reset |= SD_EXIST;
+		} else {
+			pcr->need_release |= SD_EXIST;
+			pcr->need_reset &= ~SD_EXIST;
+		}
+	}
+
+	if (int_reg & MS_INT) {
+		if (int_reg & MS_EXIST) {
+			pcr->need_reset |= MS_EXIST;
+		} else {
+			pcr->need_release |= MS_EXIST;

drivers/mfd/Kconfig

Quoted 7 lines

drivers/mfd/Kconfig +7 -0

+			pcr->need_reset &= ~MS_EXIST;
+		}
+	}
+
+	if (pcr->need_reset || pcr->need_release)
+		queue_delayed_work(workqueue, &pcr->carddet_work,
+				msecs_to_jiffies(200));

Why do we need a delayed work here ?

drivers/mfd/Kconfig

Quoted 7 lines

drivers/mfd/Kconfig +6 -0

+static void rtsx_pci_enter_idle(unsigned long __data)
+{
+	struct rtsx_pcr *pcr = (struct rtsx_pcr *)__data;
+
+	queue_work(workqueue, &pcr->idle_work);
+}

OT: We need threaded timers...

drivers/mfd/Kconfig

Quoted 5 lines

drivers/mfd/Kconfig +5 -0

+static int __init rtsx_pci_drv_init(void)
+{
+	workqueue = create_freezable_workqueue("rtsx_pci_wq");
+	if (!workqueue)
+		return -ENOMEM;

Are you sure you really need to create your won workqueue ? My guess is that you probably don't.

From: Wei WANG <[email protected]>

Realtek PCI-E Memstick card host driver is used to access Memstick card, with the help of Realtek PCI-E card reader MFD driver.

Signed-off-by Wei WANG <[email protected]>

From: Wei WANG <[email protected]>

Support for Realtek PCI-Express driver-based card readers including rts5209 and rts5229.

v2:
1. Using platform device to replace realtek slot bus

v3:
1. Fix a bug that DMA out of SW-IOMMU space in Lenovo Thinkpad x121e
2. Tested by Borislav Petkov <[email protected]>

v4:
1. Fulfill power management callbacks

v5:
1. Support Memstick card

v6:
1. Fix some coding style

Wei WANG (3):
drivers/mfd: Add realtek pcie card reader driver drivers/mmc: Add realtek pcie sdmmc host driver drivers/memstick: Add realtek pcie memstick host driver

Quoted 4 lines

Wei WANG (3):
drivers/mfd: Add realtek pcie card reader driver drivers/mmc: Add realtek pcie sdmmc host driver drivers/memstick: Add realtek pcie memstick host driver

I have a recent HP Pavilion dv6 with this card reader, 10ec:5209 (rev 01). I just applied these patches on top of 3.6-rc7. Appears to work properly with a SanDisk 8GB SDHC card. I don't have a memstick to test.

For patches 1 & 2, feel free to add my:

Tested-by Philip J. Turmel <[email protected]>

So, I think that this driver has seen a bunch of testing and reviewing and we might start considering upstreaming it. There are a bunch of laptops integrating those readers and maybe a single three-month-ish -rc period of testing wouldn't hurt before it appears upstream.

Now, AFAICT, there is another driver in staging which supports the same or a subset of the cardreaders this driver does so I don't know what Realsil want to do with that. Wei?

And since this driver touches multiple drivers/{mfd,mmc,memstick} subdirs, maybe akpm would like to merge it? At least I haven't seen any other maintainers complaining about its design or wanting to take it so

Quoted 5 lines · Borislav Petkov

So, I think that this driver has seen a bunch of testing and reviewing and we might start considering upstreaming it. There are a bunch of laptops integrating those readers and maybe a single three-month-ish -rc period of testing wouldn't hurt before it appears upstream.

Quoted 7 lines

Now, AFAICT, there is another driver in staging which supports the same or a subset of the cardreaders this driver does so I don't know what Realsil want to do with that. Wei?

And since this driver touches multiple drivers/{mfd,mmc,memstick} subdirs, maybe akpm would like to merge it? At least I haven't seen any other maintainers complaining about its design or wanting to take it so

I think you've missed the mails -- Alex Dubov has acked the memstick portion, Samuel Ortiz has said he'll push the MFD driver for 3.7, and I've pushed the MMC driver into mmc-next for 3.7. So, I think we should merge it. I don't think we need akpm, since there are no build-time dependencies involved.

Quoted 10 lines · Chris Ball

Quoted 9 lines · Borislav Petkov

So, I think that this driver has seen a bunch of testing and reviewing and we might start considering upstreaming it. There are a bunch of laptops integrating those readers and maybe a single three-month-ish -rc period of testing wouldn't hurt before it appears upstream.

Now, AFAICT, there is another driver in staging which supports the same or a subset of the cardreaders this driver does so I don't know what Realsil want to do with that. Wei?

Quoted 8 lines

Quoted 3 lines

And since this driver touches multiple drivers/{mfd,mmc,memstick} subdirs, maybe akpm would like to merge it? At least I haven't seen any other maintainers complaining about its design or wanting to take it so

I think you've missed the mails -- Alex Dubov has acked the memstick portion, Samuel Ortiz has said he'll push the MFD driver for 3.7, and I've pushed the MMC driver into mmc-next for 3.7. So, I think we should merge it. I don't think we need akpm, since there are no build-time dependencies involved.

Great, all is taken care of then.

Only the staging driver remains, I believe the CONFIG_RTS_PSTOR one. Wei?

Thanks.

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Quoted 3 lines · wwang

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging.

Quoted 6 lines · Dan Carpenter

Quoted 3 lines · wwang

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging.

I agree. wwang, want me to delet the staging driver now? I don't want "dead" code in the tree, especially as you don't want to maintain it anymore.

thanks,

greg k-h

Quoted 11 lines · Greg KH

Quoted 6 lines · Dan Carpenter

Quoted 3 lines · wwang

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging.

I agree. wwang, want me to delet the staging driver now? I don't want "dead" code in the tree, especially as you don't want to maintain it anymore.

Quoted 3 lines

thanks,

greg k-h

Hi Greg:

OK. You can delete it now, please.
And I will push my new driver to MFD and MMC subsystem.

Quoted 17 lines · wwang

Quoted 7 lines · Greg KH

Quoted 6 lines · Dan Carpenter

Quoted 3 lines · wwang

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging.

Quoted 7 lines

I agree. wwang, want me to delet the staging driver now? I don't want "dead" code in the tree, especially as you don't want to maintain it anymore.

thanks,

greg k-h

Hi Greg:

Quoted 2 lines

OK. You can delete it now, please.
And I will push my new driver to MFD and MMC subsystem.

Ok, just to confirm, you want me to delete the
drivers/staging/rts_pstor/* code, right?

thanks,

greg k-h

Quoted 23 lines · Greg KH

Quoted 12 lines · wwang

Quoted 11 lines · Greg KH

Quoted 6 lines · Dan Carpenter

Quoted 3 lines · wwang

We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging.

I agree. wwang, want me to delet the staging driver now? I don't want "dead" code in the tree, especially as you don't want to maintain it anymore.

Quoted 7 lines

Quoted 3 lines

thanks,

greg k-h

Hi Greg:

OK. You can delete it now, please.
And I will push my new driver to MFD and MMC subsystem.

Ok, just to confirm, you want me to delete the
drivers/staging/rts_pstor/* code, right?

Quoted 3 lines

thanks,

greg k-h

Hi Greg:

Yes, you can delete drivers/staging/rts_pstor