[PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

In the previous batch (https://lkml.org/lkml/2017/11/24/428)
I sent 22 patches for TMIO MMC.

14 patches were applied, the rest is under discussion.

This series consists of 16 patches.

Patch 1-4:  repost from v2.
            (Wolfram gave Reviewed by, so I moved them to the head)

Patch 5-11: new patches  (cleanups of WP flag)

Patch 12: updated per Wolfram

Patch 13: repost  (almost reviewed)

Patch 14: updated

Patch 15: new

Patch 16: repost (almost reviewed)


Masahiro Yamada (16):
  mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
  mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
  mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
  mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
  mmc: slot-gpio: add a helper to check capability of GPIO WP detection
  mmc: tmio: refactor .get_ro hook
  mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own
    flag
  sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE
  mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property
  mmc: tmio: support IP-builtin card detection logic
  mmc: tmio: fix never-detected card insertion bug
  mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
  mmc: tmio: clear force_pio flag before starting data transfer
  mmc: tmio: remove useless TMIO_MASK_CMD handling in
    tmio_mmc_host_probe()

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |   1 -
 arch/sh/boards/mach-kfr2r09/setup.c                |   2 +-
 drivers/mmc/core/slot-gpio.c                       |   8 ++
 drivers/mmc/host/renesas_sdhi_core.c               |  18 ++-
 drivers/mmc/host/renesas_sdhi_internal_dmac.c      |  12 +-
 drivers/mmc/host/renesas_sdhi_sys_dmac.c           |  20 ++-
 drivers/mmc/host/tmio_mmc.c                        |  11 +-
 drivers/mmc/host/tmio_mmc.h                        |   7 +-
 drivers/mmc/host/tmio_mmc_core.c                   | 139 +++++++++++----------
 include/linux/mfd/tmio.h                           |   1 -
 include/linux/mmc/slot-gpio.h                      |   1 +
 11 files changed, 120 insertions(+), 100 deletions(-)

-- 
2.7.4

[PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

In the previous batch (https://lkml.org/lkml/2017/11/24/428)
I sent 22 patches for TMIO MMC.

14 patches were applied, the rest is under discussion.

This series consists of 16 patches.

Patch 1-4:  repost from v2.
            (Wolfram gave Reviewed by, so I moved them to the head)

Patch 5-11: new patches  (cleanups of WP flag)

Patch 12: updated per Wolfram

Patch 13: repost  (almost reviewed)

Patch 14: updated

Patch 15: new

Patch 16: repost (almost reviewed)


Masahiro Yamada (16):
  mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
  mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
  mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
  mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
  mmc: slot-gpio: add a helper to check capability of GPIO WP detection
  mmc: tmio: refactor .get_ro hook
  mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own
    flag
  sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
  mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE
  mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property
  mmc: tmio: support IP-builtin card detection logic
  mmc: tmio: fix never-detected card insertion bug
  mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
  mmc: tmio: clear force_pio flag before starting data transfer
  mmc: tmio: remove useless TMIO_MASK_CMD handling in
    tmio_mmc_host_probe()

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |   1 -
 arch/sh/boards/mach-kfr2r09/setup.c                |   2 +-
 drivers/mmc/core/slot-gpio.c                       |   8 ++
 drivers/mmc/host/renesas_sdhi_core.c               |  18 ++-
 drivers/mmc/host/renesas_sdhi_internal_dmac.c      |  12 +-
 drivers/mmc/host/renesas_sdhi_sys_dmac.c           |  20 ++-
 drivers/mmc/host/tmio_mmc.c                        |  11 +-
 drivers/mmc/host/tmio_mmc.h                        |   7 +-
 drivers/mmc/host/tmio_mmc_core.c                   | 139 +++++++++++----------
 include/linux/mfd/tmio.h                           |   1 -
 include/linux/mmc/slot-gpio.h                      |   1 +
 11 files changed, 120 insertions(+), 100 deletions(-)

-- 
2.7.4

[PATCH v3 01/16] mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()

[Masahiro Yamada]

The register region is ioremap'ed in the tmio_mmc_host_probe(), i.e.
drivers cannot get access to the hardware before mmc_add_host().

Actually, renesas_sdhi_core.c reads out the CTL_VERSION register to
complete the platform-specific settings.  However, at this point,
the MMC host is already running.

Move the register ioremap to tmio_mmc_host_alloc() so that drivers
can perform platform-specific settings between tmio_mmc_host_alloc()
and tmio_mmc_host_probe().

I changed tmio_mmc_host_alloc() to return an error pointer to
propagate the return code from devm_ioremap_resource().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

Changes in v3: None
Changes in v2: None

 drivers/mmc/host/renesas_sdhi_core.c |  4 ++--
 drivers/mmc/host/tmio_mmc.c          |  4 +++-
 drivers/mmc/host/tmio_mmc_core.c     | 16 +++++++++-------
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index 6a2988b..ccdde27 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -512,8 +512,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 	}
 
 	host = tmio_mmc_host_alloc(pdev);
-	if (!host)
-		return -ENOMEM;
+	if (IS_ERR(host))
+		return PTR_ERR(host);
 
 	if (of_data) {
 		mmc_data->flags |= of_data->tmio_flags;
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index ccfbc15..d660816 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -93,8 +93,10 @@ static int tmio_mmc_probe(struct platform_device *pdev)
 	pdata->flags |= TMIO_MMC_HAVE_HIGH_REG;
 
 	host = tmio_mmc_host_alloc(pdev);
-	if (!host)
+	if (IS_ERR(host)) {
+		ret = PTR_ERR(host);
 		goto cell_disable;
+	}
 
 	/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
 	host->bus_shift = resource_size(res) >> 10;
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 610f26f..5f0f12a 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1150,12 +1150,20 @@ tmio_mmc_host_alloc(struct platform_device *pdev)
 {
 	struct tmio_mmc_host *host;
 	struct mmc_host *mmc;
+	struct resource *res;
+	void __iomem *ctl;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ctl = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(ctl))
+		return ERR_CAST(ctl);
 
 	mmc = mmc_alloc_host(sizeof(struct tmio_mmc_host), &pdev->dev);
 	if (!mmc)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	host = mmc_priv(mmc);
+	host->ctl = ctl;
 	host->mmc = mmc;
 	host->pdev = pdev;
 	host->ops = tmio_mmc_ops;
@@ -1177,7 +1185,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 {
 	struct platform_device *pdev = _host->pdev;
 	struct mmc_host *mmc = _host->mmc;
-	struct resource *res_ctl;
 	int ret;
 	u32 irq_mask = TMIO_MASK_CMD;
 
@@ -1186,11 +1193,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 	if (!(pdata->flags & TMIO_MMC_HAS_IDLE_WAIT))
 		_host->write16_hook = NULL;
 
-	res_ctl = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	_host->ctl = devm_ioremap_resource(&pdev->dev, res_ctl);
-	if (IS_ERR(_host->ctl))
-		return PTR_ERR(_host->ctl);
-
 	ret = mmc_of_parse(mmc);
 	if (ret < 0)
 		return ret;
-- 
2.7.4

[PATCH v3 02/16] mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()

[Masahiro Yamada]

The clock is enabled in the tmio_mmc_host_probe().  It also prevents
drivers from performing platform-specific settings before mmc_add_host()
because the register access generally requires a clock.

Enable/disable the clock in drivers' probe/remove.  Also, I passed
tmio_mmc_data to tmio_mmc_host_alloc() because renesas_sdhi_clk_enable()
needs it to get the private data from tmio_mmc_host.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

Changes in v3: None
Changes in v2:
  - Newly added

 drivers/mmc/host/renesas_sdhi_core.c | 13 ++++++++++---
 drivers/mmc/host/tmio_mmc.c          |  7 +++++--
 drivers/mmc/host/tmio_mmc.h          |  4 ++--
 drivers/mmc/host/tmio_mmc_core.c     | 33 +++++++++++++--------------------
 4 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index ccdde27..e18a1c5 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -511,7 +511,7 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 						"state_uhs");
 	}
 
-	host = tmio_mmc_host_alloc(pdev);
+	host = tmio_mmc_host_alloc(pdev, mmc_data);
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
@@ -571,10 +571,14 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 	/* All SDHI have SDIO status bits which must be 1 */
 	mmc_data->flags |= TMIO_MMC_SDIO_STATUS_SETBITS;
 
-	ret = tmio_mmc_host_probe(host, mmc_data, dma_ops);
-	if (ret < 0)
+	ret = renesas_sdhi_clk_enable(host);
+	if (ret)
 		goto efree;
 
+	ret = tmio_mmc_host_probe(host, dma_ops);
+	if (ret < 0)
+		goto edisclk;
+
 	/* One Gen2 SDHI incarnation does NOT have a CBSY bit */
 	if (sd_ctrl_read16(host, CTL_VERSION) == SDHI_VER_GEN2_SDR50)
 		mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY;
@@ -635,6 +639,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 
 eirq:
 	tmio_mmc_host_remove(host);
+edisclk:
+	renesas_sdhi_clk_disable(host);
 efree:
 	tmio_mmc_host_free(host);
 
@@ -647,6 +653,7 @@ int renesas_sdhi_remove(struct platform_device *pdev)
 	struct tmio_mmc_host *host = platform_get_drvdata(pdev);
 
 	tmio_mmc_host_remove(host);
+	renesas_sdhi_clk_disable(host);
 
 	return 0;
 }
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index d660816..11b87ce 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -92,7 +92,7 @@ static int tmio_mmc_probe(struct platform_device *pdev)
 
 	pdata->flags |= TMIO_MMC_HAVE_HIGH_REG;
 
-	host = tmio_mmc_host_alloc(pdev);
+	host = tmio_mmc_host_alloc(pdev, pdata);
 	if (IS_ERR(host)) {
 		ret = PTR_ERR(host);
 		goto cell_disable;
@@ -101,7 +101,10 @@ static int tmio_mmc_probe(struct platform_device *pdev)
 	/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
 	host->bus_shift = resource_size(res) >> 10;
 
-	ret = tmio_mmc_host_probe(host, pdata, NULL);
+	host->mmc->f_max = pdata->hclk;
+	host->mmc->f_min = pdata->hclk / 512;
+
+	ret = tmio_mmc_host_probe(host, NULL);
 	if (ret)
 		goto host_free;
 
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 27894474..f46d282 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -195,10 +195,10 @@ struct tmio_mmc_host {
 	const struct tmio_mmc_dma_ops *dma_ops;
 };
 
-struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
+struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
+					  struct tmio_mmc_data *pdata);
 void tmio_mmc_host_free(struct tmio_mmc_host *host);
 int tmio_mmc_host_probe(struct tmio_mmc_host *host,
-			struct tmio_mmc_data *pdata,
 			const struct tmio_mmc_dma_ops *dma_ops);
 void tmio_mmc_host_remove(struct tmio_mmc_host *host);
 void tmio_mmc_do_data_irq(struct tmio_mmc_host *host);
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 5f0f12a..55442ed 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1145,8 +1145,8 @@ static void tmio_mmc_of_parse(struct platform_device *pdev,
 		pdata->flags |= TMIO_MMC_WRPROTECT_DISABLE;
 }
 
-struct tmio_mmc_host*
-tmio_mmc_host_alloc(struct platform_device *pdev)
+struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
+					  struct tmio_mmc_data *pdata)
 {
 	struct tmio_mmc_host *host;
 	struct mmc_host *mmc;
@@ -1166,9 +1166,12 @@ tmio_mmc_host_alloc(struct platform_device *pdev)
 	host->ctl = ctl;
 	host->mmc = mmc;
 	host->pdev = pdev;
+	host->pdata = pdata;
 	host->ops = tmio_mmc_ops;
 	mmc->ops = &host->ops;
 
+	platform_set_drvdata(pdev, host);
+
 	return host;
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_host_alloc);
@@ -1180,14 +1183,21 @@ void tmio_mmc_host_free(struct tmio_mmc_host *host)
 EXPORT_SYMBOL_GPL(tmio_mmc_host_free);
 
 int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
-			struct tmio_mmc_data *pdata,
 			const struct tmio_mmc_dma_ops *dma_ops)
 {
 	struct platform_device *pdev = _host->pdev;
+	struct tmio_mmc_data *pdata = _host->pdata;
 	struct mmc_host *mmc = _host->mmc;
 	int ret;
 	u32 irq_mask = TMIO_MASK_CMD;
 
+	/*
+	 * Check the sanity of mmc->f_min to prevent tmio_mmc_set_clock() from
+	 * looping forever...
+	 */
+	if (mmc->f_min == 0)
+		return -EINVAL;
+
 	tmio_mmc_of_parse(pdev, pdata);
 
 	if (!(pdata->flags & TMIO_MMC_HAS_IDLE_WAIT))
@@ -1197,9 +1207,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 	if (ret < 0)
 		return ret;
 
-	_host->pdata = pdata;
-	platform_set_drvdata(pdev, _host);
-
 	_host->set_pwr = pdata->set_pwr;
 	_host->set_clk_div = pdata->set_clk_div;
 
@@ -1247,18 +1254,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 	if (pdata->flags & TMIO_MMC_MIN_RCAR2)
 		_host->native_hotplug = true;
 
-	if (tmio_mmc_clk_enable(_host) < 0) {
-		mmc->f_max = pdata->hclk;
-		mmc->f_min = mmc->f_max / 512;
-	}
-
-	/*
-	 * Check the sanity of mmc->f_min to prevent tmio_mmc_set_clock() from
-	 * looping forever...
-	 */
-	if (mmc->f_min == 0)
-		return -EINVAL;
-
 	/*
 	 * While using internal tmio hardware logic for card detection, we need
 	 * to ensure it stays powered for it to work.
@@ -1336,8 +1331,6 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
 
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-
-	tmio_mmc_clk_disable(host);
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_host_remove);
 
-- 
2.7.4

[PATCH v3 03/16] mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()

[Masahiro Yamada]

mmc_of_parse() parses various DT properties and sets capability flags
accordingly.  However, drivers have no chance to run platform init
code depending on such flags because mmc_of_parse() is called from
tmio_mmc_host_probe().

Move mmc_of_parse() to tmio_mmc_host_alloc() so that drivers can
handle capabilities before mmc_add_host().  Move tmio_mmc_of_parse()
likewise.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

Changes in v3: None
Changes in v2:
  - Newly added

 drivers/mmc/host/tmio_mmc_core.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 55442ed..fc9b28d 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1152,6 +1152,7 @@ struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
 	struct mmc_host *mmc;
 	struct resource *res;
 	void __iomem *ctl;
+	int ret;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	ctl = devm_ioremap_resource(&pdev->dev, res);
@@ -1170,9 +1171,21 @@ struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
 	host->ops = tmio_mmc_ops;
 	mmc->ops = &host->ops;
 
+	ret = mmc_of_parse(host->mmc);
+	if (ret) {
+		host = ERR_PTR(ret);
+		goto free;
+	}
+
+	tmio_mmc_of_parse(pdev, pdata);
+
 	platform_set_drvdata(pdev, host);
 
 	return host;
+free:
+	mmc_free_host(mmc);
+
+	return host;
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_host_alloc);
 
@@ -1198,15 +1211,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 	if (mmc->f_min == 0)
 		return -EINVAL;
 
-	tmio_mmc_of_parse(pdev, pdata);
-
 	if (!(pdata->flags & TMIO_MMC_HAS_IDLE_WAIT))
 		_host->write16_hook = NULL;
 
-	ret = mmc_of_parse(mmc);
-	if (ret < 0)
-		return ret;
-
 	_host->set_pwr = pdata->set_pwr;
 	_host->set_clk_div = pdata->set_clk_div;
 
-- 
2.7.4

[PATCH v3 04/16] mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument

[Masahiro Yamada]

Drivers need to set up various struct members for tmio_mmc_host before
calling tmio_mmc_host_probe().  Do likewise for host->dma_ops instead
of passing it as a function argument.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---

Changes in v3: None
Changes in v2: None

 drivers/mmc/host/renesas_sdhi_core.c | 3 ++-
 drivers/mmc/host/tmio_mmc.c          | 2 +-
 drivers/mmc/host/tmio_mmc.h          | 3 +--
 drivers/mmc/host/tmio_mmc_core.c     | 4 +---
 4 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index e18a1c5..80943fa 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -532,6 +532,7 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 	host->clk_update	= renesas_sdhi_clk_update;
 	host->clk_disable	= renesas_sdhi_clk_disable;
 	host->multi_io_quirk	= renesas_sdhi_multi_io_quirk;
+	host->dma_ops		= dma_ops;
 
 	/* SDR speeds are only available on Gen2+ */
 	if (mmc_data->flags & TMIO_MMC_MIN_RCAR2) {
@@ -575,7 +576,7 @@ int renesas_sdhi_probe(struct platform_device *pdev,
 	if (ret)
 		goto efree;
 
-	ret = tmio_mmc_host_probe(host, dma_ops);
+	ret = tmio_mmc_host_probe(host);
 	if (ret < 0)
 		goto edisclk;
 
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 11b87ce..43a2ea5 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -104,7 +104,7 @@ static int tmio_mmc_probe(struct platform_device *pdev)
 	host->mmc->f_max = pdata->hclk;
 	host->mmc->f_min = pdata->hclk / 512;
 
-	ret = tmio_mmc_host_probe(host, NULL);
+	ret = tmio_mmc_host_probe(host);
 	if (ret)
 		goto host_free;
 
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index f46d282..7609434 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -198,8 +198,7 @@ struct tmio_mmc_host {
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
 					  struct tmio_mmc_data *pdata);
 void tmio_mmc_host_free(struct tmio_mmc_host *host);
-int tmio_mmc_host_probe(struct tmio_mmc_host *host,
-			const struct tmio_mmc_dma_ops *dma_ops);
+int tmio_mmc_host_probe(struct tmio_mmc_host *host);
 void tmio_mmc_host_remove(struct tmio_mmc_host *host);
 void tmio_mmc_do_data_irq(struct tmio_mmc_host *host);
 
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index fc9b28d..d092b0f 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1195,8 +1195,7 @@ void tmio_mmc_host_free(struct tmio_mmc_host *host)
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_host_free);
 
-int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
-			const struct tmio_mmc_dma_ops *dma_ops)
+int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 {
 	struct platform_device *pdev = _host->pdev;
 	struct tmio_mmc_data *pdata = _host->pdata;
@@ -1296,7 +1295,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 	INIT_WORK(&_host->done, tmio_mmc_done_work);
 
 	/* See if we also get DMA */
-	_host->dma_ops = dma_ops;
 	tmio_mmc_request_dma(_host, pdata);
 
 	pm_runtime_set_active(&pdev->dev);
-- 
2.7.4

[PATCH v3 05/16] mmc: slot-gpio: add a helper to check capability of GPIO WP detection

[Masahiro Yamada]

Like mmc_can_gpio_cd(), mmc_can_gpio_ro() will also be useful for host
drivers to know whether GPIO write-protect detection is supported.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/core/slot-gpio.c  | 8 ++++++++
 include/linux/mmc/slot-gpio.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index f7c6e05..3698b05 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -305,3 +305,11 @@ int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
 	return 0;
 }
 EXPORT_SYMBOL(mmc_gpiod_request_ro);
+
+bool mmc_can_gpio_ro(struct mmc_host *host)
+{
+	struct mmc_gpio *ctx = host->slot.handler_priv;
+
+	return ctx->ro_gpio ? true : false;
+}
+EXPORT_SYMBOL(mmc_can_gpio_ro);
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 82f0d28..91f1ba0 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -33,5 +33,6 @@ void mmc_gpio_set_cd_isr(struct mmc_host *host,
 			 irqreturn_t (*isr)(int irq, void *dev_id));
 void mmc_gpiod_request_cd_irq(struct mmc_host *host);
 bool mmc_can_gpio_cd(struct mmc_host *host);
+bool mmc_can_gpio_ro(struct mmc_host *host);
 
 #endif
-- 
2.7.4

[PATCH v3 06/16] mmc: tmio: refactor .get_ro hook

[Masahiro Yamada]

This IP provides the write protect signal level in the status
register, but it is also possible to use GPIO for WP.  They are
exclusive, so it is not efficient to call mmc_gpio_get_ro() every
time from tmio_mmc_get_ro() if we know gpio_ro is not used.

Check the capability of gpio_ro just once in the probe function,
then set mmc_gpio_get_ro to .get_ro if it is the case.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/host/tmio_mmc_core.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index d092b0f..0032707 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1076,15 +1076,9 @@ static int tmio_mmc_get_ro(struct mmc_host *mmc)
 {
 	struct tmio_mmc_host *host = mmc_priv(mmc);
 	struct tmio_mmc_data *pdata = host->pdata;
-	int ret = mmc_gpio_get_ro(mmc);
 
-	if (ret >= 0)
-		return ret;
-
-	ret = !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
-		(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
-
-	return ret;
+	return !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
+		 (sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
 }
 
 static int tmio_multi_io_quirk(struct mmc_card *card,
@@ -1247,6 +1241,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 	}
 	mmc->max_seg_size = mmc->max_req_size;
 
+	if (mmc_can_gpio_ro(mmc))
+		_host->ops.get_ro = mmc_gpio_get_ro;
+
 	_host->native_hotplug = !(mmc_can_gpio_cd(mmc) ||
 				  mmc->caps & MMC_CAP_NEEDS_POLL ||
 				  !mmc_card_is_removable(mmc));
-- 
2.7.4

[PATCH v3 07/16] mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Masahiro Yamada]

TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.

The flag is propagated as follows:
       renesas_sdhi_of_data::capabilities2
    -> tmio_mmc_data::capabilities2
    -> mmc_host::caps2

Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
(i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
logic and GPIO detection).

The TMIO MMC drivers do not set-up gpio_ro by themselves.  Only the
possibility, if any, would be DT specifies "wp-gpios" property, and
gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse().
However, it does not make sense to specify "wp-gpios" property and
TMIO_MMC_WRPROTECT_DISABLE at the same time.

I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/,
and I did not see any Renesas boards with "wp-gpios".  So, this
conversion should be safe.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/host/renesas_sdhi_internal_dmac.c |  6 +++---
 drivers/mmc/host/renesas_sdhi_sys_dmac.c      | 16 ++++++++--------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 02c2724..0d1f95e 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -71,11 +71,11 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
 };
 
 static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
-	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
-			  TMIO_MMC_MIN_RCAR2,
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
+			  TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_CMD23,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 	.bus_shift	= 2,
 	.scc_offset	= 0x1000,
 	.taps		= rcar_gen3_scc_taps,
diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index c8a74b2..afdb66b 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -40,9 +40,9 @@ static const struct renesas_sdhi_of_data of_rz_compatible = {
 };
 
 static const struct renesas_sdhi_of_data of_rcar_gen1_compatible = {
-	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL,
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 };
 
 /* Definitions for sampling clocks */
@@ -58,11 +58,11 @@ static struct renesas_sdhi_scc rcar_gen2_scc_taps[] = {
 };
 
 static const struct renesas_sdhi_of_data of_rcar_gen2_compatible = {
-	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
-			  TMIO_MMC_MIN_RCAR2,
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
+			  TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_CMD23,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 	.dma_buswidth	= DMA_SLAVE_BUSWIDTH_4_BYTES,
 	.dma_rx_offset	= 0x2000,
 	.scc_offset	= 0x0300,
@@ -79,11 +79,11 @@ static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
 };
 
 static const struct renesas_sdhi_of_data of_rcar_gen3_compatible = {
-	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
-			  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_HAVE_CBSY |
-			  TMIO_MMC_MIN_RCAR2,
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_CLK_ACTUAL |
+			  TMIO_MMC_HAVE_CBSY | TMIO_MMC_MIN_RCAR2,
 	.capabilities	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
 			  MMC_CAP_CMD23,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 	.bus_shift	= 2,
 	.scc_offset	= 0x1000,
 	.taps		= rcar_gen3_scc_taps,
-- 
2.7.4

[PATCH v3 08/16] sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Masahiro Yamada]

TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.

The flag is propagated as follows:
    tmio_mmc_data::capabilities2 -> mmc_host::caps2

Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
(i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
logic and GPIO detection).

The TMIO MMC drivers do not set-up gpio_ro by themselves, so gpio_ro
is obviously unused by legacy boards like this.  So, this conversion
should be safe.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index 5deb2d8..6af7777 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -375,8 +375,8 @@ static struct resource kfr2r09_sh_sdhi0_resources[] = {
 static struct tmio_mmc_data sh7724_sdhi0_data = {
 	.chan_priv_tx	= (void *)SHDMA_SLAVE_SDHI0_TX,
 	.chan_priv_rx	= (void *)SHDMA_SLAVE_SDHI0_RX,
-	.flags		= TMIO_MMC_WRPROTECT_DISABLE,
 	.capabilities	= MMC_CAP_SDIO_IRQ,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 };
 
 static struct platform_device kfr2r09_sh_sdhi0_device = {
-- 
2.7.4

[PATCH v3 08/16] sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Masahiro Yamada]

TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.

The flag is propagated as follows:
    tmio_mmc_data::capabilities2 -> mmc_host::caps2

Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
(i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
logic and GPIO detection).

The TMIO MMC drivers do not set-up gpio_ro by themselves, so gpio_ro
is obviously unused by legacy boards like this.  So, this conversion
should be safe.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index 5deb2d8..6af7777 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -375,8 +375,8 @@ static struct resource kfr2r09_sh_sdhi0_resources[] = {
 static struct tmio_mmc_data sh7724_sdhi0_data = {
 	.chan_priv_tx	= (void *)SHDMA_SLAVE_SDHI0_TX,
 	.chan_priv_rx	= (void *)SHDMA_SLAVE_SDHI0_RX,
-	.flags		= TMIO_MMC_WRPROTECT_DISABLE,
 	.capabilities	= MMC_CAP_SDIO_IRQ,
+	.capabilities2	= MMC_CAP2_NO_WRITE_PROTECT,
 };
 
 static struct platform_device kfr2r09_sh_sdhi0_device = {
-- 
2.7.4

[PATCH v3 09/16] mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Masahiro Yamada]

TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.

Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
(i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
logic and GPIO detection).

The TMIO MMC drivers do not set-up gpio_ro by themselves.  Only the
possibility, if any, would be DT specifies "wp-gpios" property, and
gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse().
However, it does not make sense to specify "wp-gpios" property and
"toshiba,mmc-wrprotect-disable" at the same time.

I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/,
and I did not see any Renesas boards with "wp-gpios".  So, this
conversion should be safe.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/host/tmio_mmc_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 0032707..bdbff2d 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1128,7 +1128,7 @@ static int tmio_mmc_init_ocr(struct tmio_mmc_host *host)
 }
 
 static void tmio_mmc_of_parse(struct platform_device *pdev,
-			      struct tmio_mmc_data *pdata)
+			      struct mmc_host *mmc)
 {
 	const struct device_node *np = pdev->dev.of_node;
 
@@ -1136,7 +1136,7 @@ static void tmio_mmc_of_parse(struct platform_device *pdev,
 		return;
 
 	if (of_get_property(np, "toshiba,mmc-wrprotect-disable", NULL))
-		pdata->flags |= TMIO_MMC_WRPROTECT_DISABLE;
+		mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
 }
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
@@ -1171,7 +1171,7 @@ struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev,
 		goto free;
 	}
 
-	tmio_mmc_of_parse(pdev, pdata);
+	tmio_mmc_of_parse(pdev, mmc);
 
 	platform_set_drvdata(pdev, host);
 
-- 
2.7.4

[PATCH v3 10/16] mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE

[Masahiro Yamada]

The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT.
No platform defines this flag any more.  Remove.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/host/tmio_mmc_core.c | 5 ++---
 include/linux/mfd/tmio.h         | 1 -
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index bdbff2d..7ad3433c 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1075,10 +1075,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 static int tmio_mmc_get_ro(struct mmc_host *mmc)
 {
 	struct tmio_mmc_host *host = mmc_priv(mmc);
-	struct tmio_mmc_data *pdata = host->pdata;
 
-	return !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
-		 (sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
+	return !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
+		 TMIO_STAT_WRPROTECT);
 }
 
 static int tmio_multi_io_quirk(struct mmc_card *card,
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index 396a103c..91f9221 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -36,7 +36,6 @@
 	} while (0)
 
 /* tmio MMC platform flags */
-#define TMIO_MMC_WRPROTECT_DISABLE	BIT(0)
 /*
  * Some controllers can support a 2-byte block size when the bus width
  * is configured in 4-bit mode.
-- 
2.7.4

[PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

This property is equivalent to "disable-wp" defined in
Documentation/devicetree/bindings/mmc/tmio_mmc.txt

The TMIO MMC core calls mmc_of_parse(), and it sets
MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present.

We do not need a vendor-specific property to do the same thing.

Let's remove the description from the dt-binding to prevent new boards
from using it.

I am keeping the driver code for existing DT files, but added
comments that this is deprecated.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 -
 drivers/mmc/host/tmio_mmc_core.c                   | 5 +++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 3c67624..cb7d40e 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -49,7 +49,6 @@ Required properties:
 	  2: R7S72100
 
 Optional properties:
-- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
 - pinctrl-names: should be "default", "state_uhs"
 - pinctrl-0: should contain default/high speed pin ctrl
 - pinctrl-1: should contain uhs mode pin ctrl
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 7ad3433c..f30ac69 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1134,6 +1134,11 @@ static void tmio_mmc_of_parse(struct platform_device *pdev,
 	if (!np)
 		return;
 
+	/*
+	 * DEPRECATED:
+	 * For new platforms, please use "disable-wp" instead of
+	 * "toshiba,mmc-wrprotect-disable"
+	 */
 	if (of_get_property(np, "toshiba,mmc-wrprotect-disable", NULL))
 		mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
 }
-- 
2.7.4

[PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

This property is equivalent to "disable-wp" defined in
Documentation/devicetree/bindings/mmc/tmio_mmc.txt

The TMIO MMC core calls mmc_of_parse(), and it sets
MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present.

We do not need a vendor-specific property to do the same thing.

Let's remove the description from the dt-binding to prevent new boards
from using it.

I am keeping the driver code for existing DT files, but added
comments that this is deprecated.

Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
---

Changes in v3:
  - newly added

Changes in v2: None

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 -
 drivers/mmc/host/tmio_mmc_core.c                   | 5 +++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 3c67624..cb7d40e 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -49,7 +49,6 @@ Required properties:
 	  2: R7S72100
 
 Optional properties:
-- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
 - pinctrl-names: should be "default", "state_uhs"
 - pinctrl-0: should contain default/high speed pin ctrl
 - pinctrl-1: should contain uhs mode pin ctrl
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 7ad3433c..f30ac69 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1134,6 +1134,11 @@ static void tmio_mmc_of_parse(struct platform_device *pdev,
 	if (!np)
 		return;
 
+	/*
+	 * DEPRECATED:
+	 * For new platforms, please use "disable-wp" instead of
+	 * "toshiba,mmc-wrprotect-disable"
+	 */
 	if (of_get_property(np, "toshiba,mmc-wrprotect-disable", NULL))
 		mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
 }
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 12/16] mmc: tmio: support IP-builtin card detection logic

[Masahiro Yamada]

A card detect GPIO is set up only for platforms with "cd-gpios"
DT property or TMIO_MMC_USE_GPIO_CD flag.  However, the driver
core always uses mmc_gpio_get_cd, which just fails with -ENOSYS
if ctx->cd_gpio is unset.

The bit 5 of the status register provides the current signal level
of the CD line.  Allow to use it if the GPIO is unused.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - split out GPIO CD

Changes in v2: None

 drivers/mmc/host/tmio_mmc_core.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index f30ac69..b20d5c5 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1080,6 +1080,14 @@ static int tmio_mmc_get_ro(struct mmc_host *mmc)
 		 TMIO_STAT_WRPROTECT);
 }
 
+static int tmio_mmc_get_cd(struct mmc_host *mmc)
+{
+	struct tmio_mmc_host *host = mmc_priv(mmc);
+
+	return !!(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
+		  TMIO_STAT_SIGSTATE);
+}
+
 static int tmio_multi_io_quirk(struct mmc_card *card,
 			       unsigned int direction, int blk_size)
 {
@@ -1095,7 +1103,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {
 	.request	= tmio_mmc_request,
 	.set_ios	= tmio_mmc_set_ios,
 	.get_ro         = tmio_mmc_get_ro,
-	.get_cd		= mmc_gpio_get_cd,
+	.get_cd		= tmio_mmc_get_cd,
 	.enable_sdio_irq = tmio_mmc_enable_sdio_irq,
 	.multi_io_quirk	= tmio_multi_io_quirk,
 	.hw_reset	= tmio_mmc_hw_reset,
@@ -1248,6 +1256,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 	if (mmc_can_gpio_ro(mmc))
 		_host->ops.get_ro = mmc_gpio_get_ro;
 
+	if (mmc_can_gpio_cd(mmc))
+		_host->ops.get_ro = mmc_gpio_get_cd;
+
 	_host->native_hotplug = !(mmc_can_gpio_cd(mmc) ||
 				  mmc->caps & MMC_CAP_NEEDS_POLL ||
 				  !mmc_card_is_removable(mmc));
-- 
2.7.4

[PATCH v3 13/16] mmc: tmio: fix never-detected card insertion bug

[Masahiro Yamada]

The TMIO mmc cannot detect the card insertion in native_hotplug mode
if the driver is probed without a card inserted.

The reason is obvious; all IRQs are disabled by tmio_mmc_host_probe(),
as follows:

  tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL);

The card event IRQs are first enabled by tmio_mmc_start_command() as
follows:

  if (!host->native_hotplug)
          irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
  tmio_mmc_enable_mmc_irqs(host, irq_mask);

If the driver is probed without a card, tmio_mmc_start_command() is
never called in the first place.  So, the card is never detected.

The card event IRQs must be enabled in probe/resume functions.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3: None
Changes in v2:
  - Newly added

 drivers/mmc/host/tmio_mmc_core.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index b20d5c5..0e3dc8c 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -350,8 +350,6 @@ static int tmio_mmc_start_command(struct tmio_mmc_host *host,
 			c |= TRANSFER_READ;
 	}
 
-	if (!host->native_hotplug)
-		irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
 	tmio_mmc_enable_mmc_irqs(host, irq_mask);
 
 	/* Fire off the command */
@@ -1294,11 +1292,13 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 		irq_mask |= TMIO_MASK_READOP;
 	if (!_host->chan_tx)
 		irq_mask |= TMIO_MASK_WRITEOP;
-	if (!_host->native_hotplug)
-		irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
 
 	_host->sdcard_irq_mask &= ~irq_mask;
 
+	if (_host->native_hotplug)
+		tmio_mmc_enable_mmc_irqs(_host,
+				TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
+
 	spin_lock_init(&_host->lock);
 	mutex_init(&_host->ios_lock);
 
@@ -1382,6 +1382,10 @@ int tmio_mmc_host_runtime_resume(struct device *dev)
 	if (host->clk_cache)
 		tmio_mmc_set_clock(host, host->clk_cache);
 
+	if (host->native_hotplug)
+		tmio_mmc_enable_mmc_irqs(host,
+				TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
+
 	tmio_mmc_enable_dma(host, true);
 
 	if (tmio_mmc_can_retune(host) && host->select_tuning(host))
-- 
2.7.4

[PATCH v3 14/16] mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place

[Masahiro Yamada]

As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ}
are asserted for DMA mode as well as for PIO.  I need to disable the
those IRQs in dma_ops->start hook, otherwise the DMA transfer fails
with the following error message:
  PIO IRQ in DMA mode!

Renesas chips are the same cases since I see their dma_ops->start
hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).

If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling
should be entirely moved to the core.  tmio_mmc_cmd_irq() will
be a suitable place to disable them.

The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.

    /* Unmask the IRQs we want to know about */
    if (!_host->chan_rx)
            irq_mask |= TMIO_MASK_READOP;
    if (!_host->chan_tx)
            irq_mask |= TMIO_MASK_WRITEOP;

At this point, _host->{chan_rx,chan_tx} are _always_ NULL because
tmio_mmc_request_dma() is called after this code.  Consequently,
TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not.
Remove this pointless code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - Remove the first paragraph of git-log
  - Clean up renesas drivers too

Changes in v2:
  - Newly added

 drivers/mmc/host/renesas_sdhi_internal_dmac.c |  6 ------
 drivers/mmc/host/renesas_sdhi_sys_dmac.c      |  4 ----
 drivers/mmc/host/tmio_mmc_core.c              | 20 ++++++++++----------
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 0d1f95e..693ad49 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -145,7 +145,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host *host,
 	u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
 	enum dma_data_direction dir;
 	int ret;
-	u32 irq_mask;
 
 	/* This DMAC cannot handle if sg_len is not 1 */
 	WARN_ON(host->sg_len > 1);
@@ -157,11 +156,9 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host *host,
 	if (data->flags & MMC_DATA_READ) {
 		dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
 		dir = DMA_FROM_DEVICE;
-		irq_mask = TMIO_STAT_RXRDY;
 	} else {
 		dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
 		dir = DMA_TO_DEVICE;
-		irq_mask = TMIO_STAT_TXRQ;
 	}
 
 	ret = dma_map_sg(&host->pdev->dev, sg, host->sg_len, dir);
@@ -170,9 +167,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host *host,
 
 	renesas_sdhi_internal_dmac_enable_dma(host, true);
 
-	/* disable PIO irqs to avoid "PIO IRQ in DMA mode!" */
-	tmio_mmc_disable_mmc_irqs(host, irq_mask);
-
 	/* set dma parameters */
 	renesas_sdhi_internal_dmac_dm_write(host, DM_CM_DTRAN_MODE,
 					    dtran_mode);
diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index afdb66b..393df17 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -205,8 +205,6 @@ static void renesas_sdhi_sys_dmac_start_dma_rx(struct tmio_mmc_host *host)
 		return;
 	}
 
-	tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_RXRDY);
-
 	/* The only sg element can be unaligned, use our bounce buffer then */
 	if (!aligned) {
 		sg_init_one(&host->bounce_sg, host->bounce_buf, sg->length);
@@ -280,8 +278,6 @@ static void renesas_sdhi_sys_dmac_start_dma_tx(struct tmio_mmc_host *host)
 		return;
 	}
 
-	tmio_mmc_disable_mmc_irqs(host, TMIO_STAT_TXRQ);
-
 	/* The only sg element can be unaligned, use our bounce buffer then */
 	if (!aligned) {
 		unsigned long flags;
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 0e3dc8c..731552a 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -621,15 +621,21 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host, unsigned int stat)
 	 */
 	if (host->data && (!cmd->error || cmd->error == -EILSEQ)) {
 		if (host->data->flags & MMC_DATA_READ) {
-			if (host->force_pio || !host->chan_rx)
+			if (host->force_pio || !host->chan_rx) {
 				tmio_mmc_enable_mmc_irqs(host, TMIO_MASK_READOP);
-			else
+			} else {
+				tmio_mmc_disable_mmc_irqs(host,
+							  TMIO_MASK_READOP);
 				tasklet_schedule(&host->dma_issue);
+			}
 		} else {
-			if (host->force_pio || !host->chan_tx)
+			if (host->force_pio || !host->chan_tx) {
 				tmio_mmc_enable_mmc_irqs(host, TMIO_MASK_WRITEOP);
-			else
+			} else {
+				tmio_mmc_disable_mmc_irqs(host,
+							  TMIO_MASK_WRITEOP);
 				tasklet_schedule(&host->dma_issue);
+			}
 		}
 	} else {
 		schedule_work(&host->done);
@@ -1287,12 +1293,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 	_host->sdcard_irq_mask = sd_ctrl_read16_and_16_as_32(_host, CTL_IRQ_MASK);
 	tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL);
 
-	/* Unmask the IRQs we want to know about */
-	if (!_host->chan_rx)
-		irq_mask |= TMIO_MASK_READOP;
-	if (!_host->chan_tx)
-		irq_mask |= TMIO_MASK_WRITEOP;
-
 	_host->sdcard_irq_mask &= ~irq_mask;
 
 	if (_host->native_hotplug)
-- 
2.7.4

[PATCH v3 15/16] mmc: tmio: clear force_pio flag before starting data transfer

[Masahiro Yamada]

Currently, force_pio is cleared when the driver exits.  Then, it
resulted in clearing it in multiple places since MMC drivers in
general have multiple exit points.

 tmio_mmc_reset_work - bails out on timeout
 tmio_process_mrq - error out when it cannot send a command
 tmio_mmc_finish_request - successful exit

This is error-prone since we may miss to cover all bail-out points.

To simplify the code, the data structure should be initialized just
before used since we have a single entrance.  force_pio is only used
for data transfer, so tmio_mmc_start_data() will be a suitable place
to clear this flag.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3:
  - newly added

Changes in v2: None

 drivers/mmc/host/tmio_mmc_core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 731552a..494f0b3 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -278,7 +278,6 @@ static void tmio_mmc_reset_work(struct work_struct *work)
 
 	host->cmd = NULL;
 	host->data = NULL;
-	host->force_pio = false;
 
 	spin_unlock_irqrestore(&host->lock, flags);
 
@@ -759,6 +758,7 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host,
 
 	tmio_mmc_init_sg(host, data);
 	host->data = data;
+	host->force_pio = false;
 
 	/* Set transfer length / blocksize */
 	sd_ctrl_write16(host, CTL_SD_XFER_LEN, data->blksz);
@@ -850,7 +850,6 @@ static void tmio_process_mrq(struct tmio_mmc_host *host,
 	return;
 
 fail:
-	host->force_pio = false;
 	host->mrq = NULL;
 	mrq->cmd->error = ret;
 	mmc_request_done(host->mmc, mrq);
@@ -900,7 +899,6 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host *host)
 	if (host->cmd != mrq->sbc) {
 		host->cmd = NULL;
 		host->data = NULL;
-		host->force_pio = false;
 		host->mrq = NULL;
 	}
 
-- 
2.7.4

[PATCH v3 16/16] mmc: tmio: remove useless TMIO_MASK_CMD handling in tmio_mmc_host_probe()

[Masahiro Yamada]

TMIO_MASK_CMD is properly enabled in tmio_mmc_start_command().

We have no reason to set it up in tmio_mmc_host_probe().  (If we
really wanted to set it in the probe, we would have to do likewise
when resuming.)

Even worse, the following code is extremely confusing:

  _host->sdcard_irq_mask &= ~irq_mask;

The logic is opposite between "->sdcard_irq_mask" and "irq_mask".
The intention is not clear at a glance.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

Changes in v3: None
Changes in v2:
  - Newly added

 drivers/mmc/host/tmio_mmc_core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 494f0b3..b75a51b 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -1209,7 +1209,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 	struct tmio_mmc_data *pdata = _host->pdata;
 	struct mmc_host *mmc = _host->mmc;
 	int ret;
-	u32 irq_mask = TMIO_MASK_CMD;
 
 	/*
 	 * Check the sanity of mmc->f_min to prevent tmio_mmc_set_clock() from
@@ -1291,8 +1290,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
 	_host->sdcard_irq_mask = sd_ctrl_read16_and_16_as_32(_host, CTL_IRQ_MASK);
 	tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL);
 
-	_host->sdcard_irq_mask &= ~irq_mask;
-
 	if (_host->native_hotplug)
 		tmio_mmc_enable_mmc_irqs(_host,
 				TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
-- 
2.7.4

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> This property is equivalent to "disable-wp" defined in
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt

This is mistake.

"disable-wp" is defined in

Documentation/devicetree/bindings/mmc/mmc.txt




> The TMIO MMC core calls mmc_of_parse(), and it sets
> MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present.
>
> We do not need a vendor-specific property to do the same thing.
>
> Let's remove the description from the dt-binding to prevent new boards
> from using it.
>
> I am keeping the driver code for existing DT files, but added
> comments that this is deprecated.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Changes in v3:
>   - newly added
>
> Changes in v2: None
>
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 -
>  drivers/mmc/host/tmio_mmc_core.c                   | 5 +++++
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 3c67624..cb7d40e 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -49,7 +49,6 @@ Required properties:
>           2: R7S72100
>
>  Optional properties:
> -- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
>  - pinctrl-names: should be "default", "state_uhs"
>  - pinctrl-0: should contain default/high speed pin ctrl
>  - pinctrl-1: should contain uhs mode pin ctrl
> diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
> index 7ad3433c..f30ac69 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -1134,6 +1134,11 @@ static void tmio_mmc_of_parse(struct platform_device *pdev,
>         if (!np)
>                 return;
>
> +       /*
> +        * DEPRECATED:
> +        * For new platforms, please use "disable-wp" instead of
> +        * "toshiba,mmc-wrprotect-disable"
> +        */
>         if (of_get_property(np, "toshiba,mmc-wrprotect-disable", NULL))
>                 mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
>  }
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 17 January 2018 at 17:28, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
> I sent 22 patches for TMIO MMC.
>
> 14 patches were applied, the rest is under discussion.
>
> This series consists of 16 patches.
>
> Patch 1-4:  repost from v2.
>             (Wolfram gave Reviewed by, so I moved them to the head)

Applied for next.

>
> Patch 5-11: new patches  (cleanups of WP flag)

I picked patch5 and patch6, as those seemed trivial. Unless there is a
rc9, let's aim for 4.17 for the rest.

[...]

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 17 January 2018 at 17:28, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
> I sent 22 patches for TMIO MMC.
>
> 14 patches were applied, the rest is under discussion.
>
> This series consists of 16 patches.
>
> Patch 1-4:  repost from v2.
>             (Wolfram gave Reviewed by, so I moved them to the head)

Applied for next.

>
> Patch 5-11: new patches  (cleanups of WP flag)

I picked patch5 and patch6, as those seemed trivial. Unless there is a
rc9, let's aim for 4.17 for the rest.

[...]

Kind regards
Uffe

Re: [PATCH v3 10/16] mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE

[Lee Jones]

On Thu, 18 Jan 2018, Masahiro Yamada wrote:

> The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT.
> No platform defines this flag any more.  Remove.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
> 
> Changes in v3:
>   - newly added
> 
> Changes in v2: None
> 
>  drivers/mmc/host/tmio_mmc_core.c | 5 ++---
>  include/linux/mfd/tmio.h         | 1 -
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
> index bdbff2d..7ad3433c 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -1075,10 +1075,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  static int tmio_mmc_get_ro(struct mmc_host *mmc)
>  {
>  	struct tmio_mmc_host *host = mmc_priv(mmc);
> -	struct tmio_mmc_data *pdata = host->pdata;
>  
> -	return !((pdata->flags & TMIO_MMC_WRPROTECT_DISABLE) ||
> -		 (sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
> +	return !(sd_ctrl_read16_and_16_as_32(host, CTL_STATUS) &
> +		 TMIO_STAT_WRPROTECT);
>  }
>  
>  static int tmio_multi_io_quirk(struct mmc_card *card,
> diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
> index 396a103c..91f9221 100644
> --- a/include/linux/mfd/tmio.h
> +++ b/include/linux/mfd/tmio.h
> @@ -36,7 +36,6 @@
>  	} while (0)
>  
>  /* tmio MMC platform flags */
> -#define TMIO_MMC_WRPROTECT_DISABLE	BIT(0)

If it is truly not in use after this set:

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Rob Herring]

On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> > This property is equivalent to "disable-wp" defined in
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> 
> This is mistake.
> 
> "disable-wp" is defined in
> 
> Documentation/devicetree/bindings/mmc/mmc.txt
> 
> 
> 
> 
> > The TMIO MMC core calls mmc_of_parse(), and it sets
> > MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present.
> >
> > We do not need a vendor-specific property to do the same thing.
> >
> > Let's remove the description from the dt-binding to prevent new boards
> > from using it.
> >
> > I am keeping the driver code for existing DT files, but added
> > comments that this is deprecated.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
> >
> > Changes in v3:
> >   - newly added
> >
> > Changes in v2: None
> >
> >  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 -

Other than the above,

Acked-by: Rob Herring <robh@kernel.org>

> >  drivers/mmc/host/tmio_mmc_core.c                   | 5 +++++
> >  2 files changed, 5 insertions(+), 1 deletion(-)

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Rob Herring]

On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>:
> > This property is equivalent to "disable-wp" defined in
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> 
> This is mistake.
> 
> "disable-wp" is defined in
> 
> Documentation/devicetree/bindings/mmc/mmc.txt
> 
> 
> 
> 
> > The TMIO MMC core calls mmc_of_parse(), and it sets
> > MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present.
> >
> > We do not need a vendor-specific property to do the same thing.
> >
> > Let's remove the description from the dt-binding to prevent new boards
> > from using it.
> >
> > I am keeping the driver code for existing DT files, but added
> > comments that this is deprecated.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> > ---
> >
> > Changes in v3:
> >   - newly added
> >
> > Changes in v2: None
> >
> >  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 -

Other than the above,

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

> >  drivers/mmc/host/tmio_mmc_core.c                   | 5 +++++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/16] mmc: slot-gpio: add a helper to check capability of GPIO WP detection

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Thu, Jan 18, 2018 at 01:28:05AM +0900, Masahiro Yamada wrote:
> Like mmc_can_gpio_cd(), mmc_can_gpio_ro() will also be useful for host
> drivers to know whether GPIO write-protect detection is supported.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 06/16] mmc: tmio: refactor .get_ro hook

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Thu, Jan 18, 2018 at 01:28:06AM +0900, Masahiro Yamada wrote:
> This IP provides the write protect signal level in the status
> register, but it is also possible to use GPIO for WP.  They are
> exclusive, so it is not efficient to call mmc_gpio_get_ro() every
> time from tmio_mmc_get_ro() if we know gpio_ro is not used.
> 
> Check the capability of gpio_ro just once in the probe function,
> then set mmc_gpio_get_ro to .get_ro if it is the case.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]


> I picked patch5 and patch6, as those seemed trivial. Unless there is a
> rc9, let's aim for 4.17 for the rest.

I can't find the branch where you picked these patches? I wanted to use
it to apply the rest of the patches. They don't seem to fit on v4.15
or current linus/master. Can you share this branch?

I will do reviewing now "visually". But please wait until I tested them
before applying.

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]


> I picked patch5 and patch6, as those seemed trivial. Unless there is a
> rc9, let's aim for 4.17 for the rest.

I can't find the branch where you picked these patches? I wanted to use
it to apply the rest of the patches. They don't seem to fit on v4.15
or current linus/master. Can you share this branch?

I will do reviewing now "visually". But please wait until I tested them
before applying.

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 07/16] mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Thu, Jan 18, 2018 at 01:28:07AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
> 
> The flag is propagated as follows:
>        renesas_sdhi_of_data::capabilities2
>     -> tmio_mmc_data::capabilities2
>     -> mmc_host::caps2
> 
> Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
> (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
> returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
> logic and GPIO detection).
> 
> The TMIO MMC drivers do not set-up gpio_ro by themselves.  Only the
> possibility, if any, would be DT specifies "wp-gpios" property, and
> gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse().
> However, it does not make sense to specify "wp-gpios" property and
> TMIO_MMC_WRPROTECT_DISABLE at the same time.
> 
> I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/,
> and I did not see any Renesas boards with "wp-gpios".  So, this
> conversion should be safe.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 08/16] sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Thu, Jan 18, 2018 at 01:28:08AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
> 
> The flag is propagated as follows:
>     tmio_mmc_data::capabilities2 -> mmc_host::caps2
> 
> Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
> (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
> returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
> logic and GPIO detection).
> 
> The TMIO MMC drivers do not set-up gpio_ro by themselves, so gpio_ro
> is obviously unused by legacy boards like this.  So, this conversion
> should be safe.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 08/16] sh: kfr2r09: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Thu, Jan 18, 2018 at 01:28:08AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
> 
> The flag is propagated as follows:
>     tmio_mmc_data::capabilities2 -> mmc_host::caps2
> 
> Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
> (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
> returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
> logic and GPIO detection).
> 
> The TMIO MMC drivers do not set-up gpio_ro by themselves, so gpio_ro
> is obviously unused by legacy boards like this.  So, this conversion
> should be safe.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 09/16] mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On Thu, Jan 18, 2018 at 01:28:09AM +0900, Masahiro Yamada wrote:
> TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
> 
> Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0
> (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_...
> returns 0 before calling ->get_ro() hook (i.e. it affects both IP own
> logic and GPIO detection).
> 
> The TMIO MMC drivers do not set-up gpio_ro by themselves.  Only the
> possibility, if any, would be DT specifies "wp-gpios" property, and
> gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse().
> However, it does not make sense to specify "wp-gpios" property and
> "toshiba,mmc-wrprotect-disable" at the same time.
> 
> I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/,
> and I did not see any Renesas boards with "wp-gpios".  So, this
> conversion should be safe.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

>  static void tmio_mmc_of_parse(struct platform_device *pdev,
> -			      struct tmio_mmc_data *pdata)
> +			      struct mmc_host *mmc)

I like how this cleanups improves things in various parts of the code,
like here. Nice!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 10/16] mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLE

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

On Thu, Jan 18, 2018 at 01:28:10AM +0900, Masahiro Yamada wrote:
> The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT.
> No platform defines this flag any more.  Remove.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> > This property is equivalent to "disable-wp" defined in
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> 
> This is mistake.
> 
> "disable-wp" is defined in
> 
> Documentation/devicetree/bindings/mmc/mmc.txt

With that fixed:

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>:
> > This property is equivalent to "disable-wp" defined in
> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> 
> This is mistake.
> 
> "disable-wp" is defined in
> 
> Documentation/devicetree/bindings/mmc/mmc.txt

With that fixed:

Reviewed-by: Wolfram Sang <wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 12/16] mmc: tmio: support IP-builtin card detection logic

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Thu, Jan 18, 2018 at 01:28:12AM +0900, Masahiro Yamada wrote:
> A card detect GPIO is set up only for platforms with "cd-gpios"
> DT property or TMIO_MMC_USE_GPIO_CD flag.  However, the driver
> core always uses mmc_gpio_get_cd, which just fails with -ENOSYS
> if ctx->cd_gpio is unset.
> 
> The bit 5 of the status register provides the current signal level
> of the CD line.  Allow to use it if the GPIO is unused.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

> @@ -1095,7 +1103,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {

I just wonder why the diff-tool puts 'const' in the definition. There is
no const in my version here. And there shouldn't be because we modify
the struct in this patch.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 13/16] mmc: tmio: fix never-detected card insertion bug

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

On Thu, Jan 18, 2018 at 01:28:13AM +0900, Masahiro Yamada wrote:
> The TMIO mmc cannot detect the card insertion in native_hotplug mode
> if the driver is probed without a card inserted.
> 
> The reason is obvious; all IRQs are disabled by tmio_mmc_host_probe(),
> as follows:
> 
>   tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL);
> 
> The card event IRQs are first enabled by tmio_mmc_start_command() as
> follows:
> 
>   if (!host->native_hotplug)
>           irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT);
>   tmio_mmc_enable_mmc_irqs(host, irq_mask);
> 
> If the driver is probed without a card, tmio_mmc_start_command() is
> never called in the first place.  So, the card is never detected.
> 
> The card event IRQs must be enabled in probe/resume functions.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 14/16] mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Thu, Jan 18, 2018 at 01:28:14AM +0900, Masahiro Yamada wrote:
> As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ}
> are asserted for DMA mode as well as for PIO.  I need to disable the
> those IRQs in dma_ops->start hook, otherwise the DMA transfer fails
> with the following error message:
>   PIO IRQ in DMA mode!
> 
> Renesas chips are the same cases since I see their dma_ops->start
> hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).
> 
> If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling
> should be entirely moved to the core.  tmio_mmc_cmd_irq() will
> be a suitable place to disable them.
> 
> The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.
> 
>     /* Unmask the IRQs we want to know about */
>     if (!_host->chan_rx)
>             irq_mask |= TMIO_MASK_READOP;
>     if (!_host->chan_tx)
>             irq_mask |= TMIO_MASK_WRITEOP;
> 
> At this point, _host->{chan_rx,chan_tx} are _always_ NULL because
> tmio_mmc_request_dma() is called after this code.  Consequently,
> TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not.
> Remove this pointless code.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

I need to stop reviewing here because I'd need the applied version for
checking. I hope Ulf can give me a base tomorrow.

Or Yamada-san, do you meanwhile have a git repo somewhere?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 12/16] mmc: tmio: support IP-builtin card detection logic

[Masahiro Yamada]

2018-02-08 4:34 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
> On Thu, Jan 18, 2018 at 01:28:12AM +0900, Masahiro Yamada wrote:
>> A card detect GPIO is set up only for platforms with "cd-gpios"
>> DT property or TMIO_MMC_USE_GPIO_CD flag.  However, the driver
>> core always uses mmc_gpio_get_cd, which just fails with -ENOSYS
>> if ctx->cd_gpio is unset.
>>
>> The bit 5 of the status register provides the current signal level
>> of the CD line.  Allow to use it if the GPIO is unused.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
>> @@ -1095,7 +1103,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {
>
> I just wonder why the diff-tool puts 'const' in the definition. There is
> no const in my version here. And there shouldn't be because we modify
> the struct in this patch.
>

Which kernel version are you seeing?

The following patch was applied and it is in Linus'tree.



commit c055fc75c1757b220108489038cfe60496b13865
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Sat Nov 25 01:24:41 2017 +0900

    mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data

    Currently, tmio_mmc_ops is static data and tmio_mmc_host_probe()
    updates some hooks in the static data.  This is a problem when
    two or more instances call tmio_mmc_host_probe() and each of them
    requests to use its own card_busy/start_signal_voltage_switch.

    We can borrow a solution from sdhci_alloc_host().  Copy the whole
    ops structure to host->mmc_host_ops, then override the hooks in
    malloc'ed data.  Constify tmio_mmc_ops since it is now a template
    ops used by default.

    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 14/16] mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place

[Masahiro Yamada]

2018-02-08 6:47 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
> On Thu, Jan 18, 2018 at 01:28:14AM +0900, Masahiro Yamada wrote:
>> As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ}
>> are asserted for DMA mode as well as for PIO.  I need to disable the
>> those IRQs in dma_ops->start hook, otherwise the DMA transfer fails
>> with the following error message:
>>   PIO IRQ in DMA mode!
>>
>> Renesas chips are the same cases since I see their dma_ops->start
>> hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).
>>
>> If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling
>> should be entirely moved to the core.  tmio_mmc_cmd_irq() will
>> be a suitable place to disable them.
>>
>> The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.
>>
>>     /* Unmask the IRQs we want to know about */
>>     if (!_host->chan_rx)
>>             irq_mask |= TMIO_MASK_READOP;
>>     if (!_host->chan_tx)
>>             irq_mask |= TMIO_MASK_WRITEOP;
>>
>> At this point, _host->{chan_rx,chan_tx} are _always_ NULL because
>> tmio_mmc_request_dma() is called after this code.  Consequently,
>> TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not.
>> Remove this pointless code.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> I need to stop reviewing here because I'd need the applied version for
> checking. I hope Ulf can give me a base tomorrow.
>
> Or Yamada-san, do you meanwhile have a git repo somewhere?
>

Patch 1-6 were pulled merged in this MW.

Patch 7-16 are cleanly applicable onto Linus' tree.
(commit 581e400ff935d34 as of writing)



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>> rc9, let's aim for 4.17 for the rest.
>
> I can't find the branch where you picked these patches? I wanted to use
> it to apply the rest of the patches. They don't seem to fit on v4.15
> or current linus/master. Can you share this branch?

You need to check again. :-)

Patches up and to patch6 is already in Linus' tree v.16rc1, those I
carried for quite a while on my next branch before sending them in the
PR to Linus.

>
> I will do reviewing now "visually". But please wait until I tested them
> before applying.

I am eager to apply those patches you already have reviewed (to
patch14), as those mostly seemed rather trivial and should be nice
cleanups.

Do you mind me going ahead, then you can continue and review/test the rest?

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>> rc9, let's aim for 4.17 for the rest.
>
> I can't find the branch where you picked these patches? I wanted to use
> it to apply the rest of the patches. They don't seem to fit on v4.15
> or current linus/master. Can you share this branch?

You need to check again. :-)

Patches up and to patch6 is already in Linus' tree v.16rc1, those I
carried for quite a while on my next branch before sending them in the
PR to Linus.

>
> I will do reviewing now "visually". But please wait until I tested them
> before applying.

I am eager to apply those patches you already have reviewed (to
patch14), as those mostly seemed rather trivial and should be nice
cleanups.

Do you mind me going ahead, then you can continue and review/test the rest?

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

Hi Ulf,


2018-02-14 18:36 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
> On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>>
>>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>>> rc9, let's aim for 4.17 for the rest.
>>
>> I can't find the branch where you picked these patches? I wanted to use
>> it to apply the rest of the patches. They don't seem to fit on v4.15
>> or current linus/master. Can you share this branch?
>
> You need to check again. :-)
>
> Patches up and to patch6 is already in Linus' tree v.16rc1, those I
> carried for quite a while on my next branch before sending them in the
> PR to Linus.
>
>>
>> I will do reviewing now "visually". But please wait until I tested them
>> before applying.
>
> I am eager to apply those patches you already have reviewed (to
> patch14), as those mostly seemed rather trivial and should be nice
> cleanups.
>
> Do you mind me going ahead, then you can continue and review/test the rest?
>


If you move forward, please fix-up the commit log of the patch 11.
(https://patchwork.kernel.org/patch/10170007/)


Documentation/devicetree/bindings/mmc/tmio_mmc.txt

  ->

Documentation/devicetree/bindings/mmc/mmc.txt



Thanks.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

Hi Ulf,


2018-02-14 18:36 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
> On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>>
>>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>>> rc9, let's aim for 4.17 for the rest.
>>
>> I can't find the branch where you picked these patches? I wanted to use
>> it to apply the rest of the patches. They don't seem to fit on v4.15
>> or current linus/master. Can you share this branch?
>
> You need to check again. :-)
>
> Patches up and to patch6 is already in Linus' tree v.16rc1, those I
> carried for quite a while on my next branch before sending them in the
> PR to Linus.
>
>>
>> I will do reviewing now "visually". But please wait until I tested them
>> before applying.
>
> I am eager to apply those patches you already have reviewed (to
> patch14), as those mostly seemed rather trivial and should be nice
> cleanups.
>
> Do you mind me going ahead, then you can continue and review/test the rest?
>


If you move forward, please fix-up the commit log of the patch 11.
(https://patchwork.kernel.org/patch/10170007/)


Documentation/devicetree/bindings/mmc/tmio_mmc.txt

  ->

Documentation/devicetree/bindings/mmc/mmc.txt



Thanks.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 14 February 2018 at 10:43, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Ulf,
>
>
> 2018-02-14 18:36 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
>> On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>>>
>>>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>>>> rc9, let's aim for 4.17 for the rest.
>>>
>>> I can't find the branch where you picked these patches? I wanted to use
>>> it to apply the rest of the patches. They don't seem to fit on v4.15
>>> or current linus/master. Can you share this branch?
>>
>> You need to check again. :-)
>>
>> Patches up and to patch6 is already in Linus' tree v.16rc1, those I
>> carried for quite a while on my next branch before sending them in the
>> PR to Linus.
>>
>>>
>>> I will do reviewing now "visually". But please wait until I tested them
>>> before applying.
>>
>> I am eager to apply those patches you already have reviewed (to
>> patch14), as those mostly seemed rather trivial and should be nice
>> cleanups.
>>
>> Do you mind me going ahead, then you can continue and review/test the rest?
>>
>
>
> If you move forward, please fix-up the commit log of the patch 11.
> (https://patchwork.kernel.org/patch/10170007/)
>
>
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>
>   ->
>
> Documentation/devicetree/bindings/mmc/mmc.txt

Thanks for the reminder. Yes I can amend the patch, no worries.

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 14 February 2018 at 10:43, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Ulf,
>
>
> 2018-02-14 18:36 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
>> On 7 February 2018 at 20:11, Wolfram Sang <wsa@the-dreams.de> wrote:
>>>
>>>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>>>> rc9, let's aim for 4.17 for the rest.
>>>
>>> I can't find the branch where you picked these patches? I wanted to use
>>> it to apply the rest of the patches. They don't seem to fit on v4.15
>>> or current linus/master. Can you share this branch?
>>
>> You need to check again. :-)
>>
>> Patches up and to patch6 is already in Linus' tree v.16rc1, those I
>> carried for quite a while on my next branch before sending them in the
>> PR to Linus.
>>
>>>
>>> I will do reviewing now "visually". But please wait until I tested them
>>> before applying.
>>
>> I am eager to apply those patches you already have reviewed (to
>> patch14), as those mostly seemed rather trivial and should be nice
>> cleanups.
>>
>> Do you mind me going ahead, then you can continue and review/test the rest?
>>
>
>
> If you move forward, please fix-up the commit log of the patch 11.
> (https://patchwork.kernel.org/patch/10170007/)
>
>
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>
>   ->
>
> Documentation/devicetree/bindings/mmc/mmc.txt

Thanks for the reminder. Yes I can amend the patch, no worries.

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]


> You need to check again. :-)

Seems like it. Sorry for the noise.

> I am eager to apply those patches you already have reviewed (to
> patch14), as those mostly seemed rather trivial and should be nice
> cleanups.
> 
> Do you mind me going ahead, then you can continue and review/test the rest?

Yes, we can work incremently from there. I'll send patches if I discover
something unexpected.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]


> You need to check again. :-)

Seems like it. Sorry for the noise.

> I am eager to apply those patches you already have reviewed (to
> patch14), as those mostly seemed rather trivial and should be nice
> cleanups.
> 
> Do you mind me going ahead, then you can continue and review/test the rest?

Yes, we can work incremently from there. I'll send patches if I discover
something unexpected.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]


> You need to check again. :-)

Seems like it. Sorry for the noise.

> I am eager to apply those patches you already have reviewed (to
> patch14), as those mostly seemed rather trivial and should be nice
> cleanups.
> 
> Do you mind me going ahead, then you can continue and review/test the rest?

Yes, we can work incremently from there. I'll send patches if I discover
something unexpected.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 14 February 2018 at 11:23, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> You need to check again. :-)
>
> Seems like it. Sorry for the noise.
>
>> I am eager to apply those patches you already have reviewed (to
>> patch14), as those mostly seemed rather trivial and should be nice
>> cleanups.
>>
>> Do you mind me going ahead, then you can continue and review/test the rest?
>
> Yes, we can work incremently from there. I'll send patches if I discover
> something unexpected.
>

Great! So, applied patches 7->14.

Thanks and kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 14 February 2018 at 11:23, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> You need to check again. :-)
>
> Seems like it. Sorry for the noise.
>
>> I am eager to apply those patches you already have reviewed (to
>> patch14), as those mostly seemed rather trivial and should be nice
>> cleanups.
>>
>> Do you mind me going ahead, then you can continue and review/test the rest?
>
> Yes, we can work incremently from there. I'll send patches if I discover
> something unexpected.
>

Great! So, applied patches 7->14.

Thanks and kind regards
Uffe

Re: [PATCH v3 14/16] mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Thu, Jan 18, 2018 at 01:28:14AM +0900, Masahiro Yamada wrote:
> As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ}
> are asserted for DMA mode as well as for PIO.  I need to disable the
> those IRQs in dma_ops->start hook, otherwise the DMA transfer fails
> with the following error message:
>   PIO IRQ in DMA mode!
> 
> Renesas chips are the same cases since I see their dma_ops->start
> hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).
> 
> If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling
> should be entirely moved to the core.  tmio_mmc_cmd_irq() will
> be a suitable place to disable them.
> 
> The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.
> 
>     /* Unmask the IRQs we want to know about */
>     if (!_host->chan_rx)
>             irq_mask |= TMIO_MASK_READOP;
>     if (!_host->chan_tx)
>             irq_mask |= TMIO_MASK_WRITEOP;
> 
> At this point, _host->{chan_rx,chan_tx} are _always_ NULL because
> tmio_mmc_request_dma() is called after this code.  Consequently,
> TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not.
> Remove this pointless code.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 15/16] mmc: tmio: clear force_pio flag before starting data transfer

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Thu, Jan 18, 2018 at 01:28:15AM +0900, Masahiro Yamada wrote:
> Currently, force_pio is cleared when the driver exits.  Then, it
> resulted in clearing it in multiple places since MMC drivers in
> general have multiple exit points.
> 
>  tmio_mmc_reset_work - bails out on timeout
>  tmio_process_mrq - error out when it cannot send a command
>  tmio_mmc_finish_request - successful exit
> 
> This is error-prone since we may miss to cover all bail-out points.
> 
> To simplify the code, the data structure should be initialized just
> before used since we have a single entrance.  force_pio is only used
> for data transfer, so tmio_mmc_start_data() will be a suitable place
> to clear this flag.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 16/16] mmc: tmio: remove useless TMIO_MASK_CMD handling in tmio_mmc_host_probe()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Thu, Jan 18, 2018 at 01:28:16AM +0900, Masahiro Yamada wrote:
> TMIO_MASK_CMD is properly enabled in tmio_mmc_start_command().
> 
> We have no reason to set it up in tmio_mmc_host_probe().  (If we
> really wanted to set it in the probe, we would have to do likewise
> when resuming.)
> 
> Even worse, the following code is extremely confusing:
> 
>   _host->sdcard_irq_mask &= ~irq_mask;
> 
> The logic is opposite between "->sdcard_irq_mask" and "irq_mask".
> The intention is not clear at a glance.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Thu, Jan 18, 2018 at 01:28:00AM +0900, Masahiro Yamada wrote:
> 
> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
> I sent 22 patches for TMIO MMC.
> 
> 14 patches were applied, the rest is under discussion.
> 
> This series consists of 16 patches.

Which I tested now, so we can add

Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

to the patches except for

> Patch 12: updated per Wolfram

this one which needs a fix. I will send it as an incremental patch.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Thu, Jan 18, 2018 at 01:28:00AM +0900, Masahiro Yamada wrote:
> 
> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
> I sent 22 patches for TMIO MMC.
> 
> 14 patches were applied, the rest is under discussion.
> 
> This series consists of 16 patches.

Which I tested now, so we can add

Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

to the patches except for

> Patch 12: updated per Wolfram

this one which needs a fix. I will send it as an incremental patch.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 4 March 2018 at 23:42, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Jan 18, 2018 at 01:28:00AM +0900, Masahiro Yamada wrote:
>>
>> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
>> I sent 22 patches for TMIO MMC.
>>
>> 14 patches were applied, the rest is under discussion.
>>
>> This series consists of 16 patches.
>
> Which I tested now, so we can add
>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> to the patches except for
>
>> Patch 12: updated per Wolfram
>
> this one which needs a fix. I will send it as an incremental patch.
>

Yamada-san, Wolfram,

I have added Wolframs tags to the already applied patches and applied
that last two, 15 and 16.

They are all present in my next branch. The fix that Wolfram sent on
top, is added immediately after the commit it fixes.

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 4 March 2018 at 23:42, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Jan 18, 2018 at 01:28:00AM +0900, Masahiro Yamada wrote:
>>
>> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
>> I sent 22 patches for TMIO MMC.
>>
>> 14 patches were applied, the rest is under discussion.
>>
>> This series consists of 16 patches.
>
> Which I tested now, so we can add
>
> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> to the patches except for
>
>> Patch 12: updated per Wolfram
>
> this one which needs a fix. I will send it as an incremental patch.
>

Yamada-san, Wolfram,

I have added Wolframs tags to the already applied patches and applied
that last two, 15 and 16.

They are all present in my next branch. The fix that Wolfram sent on
top, is added immediately after the commit it fixes.

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]


> I have added Wolframs tags to the already applied patches and applied
> that last two, 15 and 16.

Thanks. Please note that patch 14 misses my Rev tag. (I gave it
yesterday but the patch was accidently applied before. One round too
early, so to say).

> They are all present in my next branch. The fix that Wolfram sent on
> top, is added immediately after the commit it fixes.

Could we also squash it, then?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]


> I have added Wolframs tags to the already applied patches and applied
> that last two, 15 and 16.

Thanks. Please note that patch 14 misses my Rev tag. (I gave it
yesterday but the patch was accidently applied before. One round too
early, so to say).

> They are all present in my next branch. The fix that Wolfram sent on
> top, is added immediately after the commit it fixes.

Could we also squash it, then?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

Hi Ulf, Wolfram,

2018-03-05 18:22 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
>
>> I have added Wolframs tags to the already applied patches and applied
>> that last two, 15 and 16.
>
> Thanks. Please note that patch 14 misses my Rev tag. (I gave it
> yesterday but the patch was accidently applied before. One round too
> early, so to say).
>
>> They are all present in my next branch. The fix that Wolfram sent on
>> top, is added immediately after the commit it fixes.
>
> Could we also squash it, then?
>

If Wolfram is fine with squashing,
that would be cleaner.

In that case, can you add Tested-by
to patch 12?




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Masahiro Yamada]

Hi Ulf, Wolfram,

2018-03-05 18:22 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
>
>> I have added Wolframs tags to the already applied patches and applied
>> that last two, 15 and 16.
>
> Thanks. Please note that patch 14 misses my Rev tag. (I gave it
> yesterday but the patch was accidently applied before. One round too
> early, so to say).
>
>> They are all present in my next branch. The fix that Wolfram sent on
>> top, is added immediately after the commit it fixes.
>
> Could we also squash it, then?
>

If Wolfram is fine with squashing,
that would be cleaner.

In that case, can you add Tested-by
to patch 12?




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]


> >> They are all present in my next branch. The fix that Wolfram sent on
> >> top, is added immediately after the commit it fixes.
> >
> > Could we also squash it, then?
> >
> 
> If Wolfram is fine with squashing,
> that would be cleaner.
> 
> In that case, can you add Tested-by
> to patch 12?

Yup, sounds best to me.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]


> >> They are all present in my next branch. The fix that Wolfram sent on
> >> top, is added immediately after the commit it fixes.
> >
> > Could we also squash it, then?
> >
> 
> If Wolfram is fine with squashing,
> that would be cleaner.
> 
> In that case, can you add Tested-by
> to patch 12?

Yup, sounds best to me.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 5 March 2018 at 10:34, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Ulf, Wolfram,
>
> 2018-03-05 18:22 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
>>
>>> I have added Wolframs tags to the already applied patches and applied
>>> that last two, 15 and 16.
>>
>> Thanks. Please note that patch 14 misses my Rev tag. (I gave it
>> yesterday but the patch was accidently applied before. One round too
>> early, so to say).

Added rev. tag.

>>
>>> They are all present in my next branch. The fix that Wolfram sent on
>>> top, is added immediately after the commit it fixes.
>>
>> Could we also squash it, then?
>>
>
> If Wolfram is fine with squashing,
> that would be cleaner.
>

Done.

> In that case, can you add Tested-by
> to patch 12?

Done.

Kind regards
Uffe

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

[Ulf Hansson]

On 5 March 2018 at 10:34, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Ulf, Wolfram,
>
> 2018-03-05 18:22 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
>>
>>> I have added Wolframs tags to the already applied patches and applied
>>> that last two, 15 and 16.
>>
>> Thanks. Please note that patch 14 misses my Rev tag. (I gave it
>> yesterday but the patch was accidently applied before. One round too
>> early, so to say).

Added rev. tag.

>>
>>> They are all present in my next branch. The fix that Wolfram sent on
>>> top, is added immediately after the commit it fixes.
>>
>> Could we also squash it, then?
>>
>
> If Wolfram is fine with squashing,
> that would be cleaner.
>

Done.

> In that case, can you add Tested-by
> to patch 12?

Done.

Kind regards
Uffe

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

2018-02-08 4:32 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
> On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
>> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> > This property is equivalent to "disable-wp" defined in
>> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>>
>> This is mistake.
>>
>> "disable-wp" is defined in
>>
>> Documentation/devicetree/bindings/mmc/mmc.txt
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>

BTW, the subject of the applied version is wrong.

In my original post:
https://patchwork.kernel.org/patch/10170007/
"toshiba,mmc-wrprotect-disable"
No space after the vendor prefix.


But, applied commit (788778b0d21a6d5cd5)
I see a space, like
"toshiba, mmc-wrprotect-disable"


I think this is a bug of patchwork.


I have seen various bugs that break
the patch format.

I filed some bug reports for patchwork,
but not sure what happened.

-- 
Best Regards
Masahiro Yamada