Skip to contentSkip to conversation

mtd: sh_flctl: pass FIFO as physical address

PATCH Applied Arnd Bergmann 3 participants 6 messages Dec 8, 2015 – Dec 19, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mtd: sh_flctl: pass FIFO as physical address

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

We also get a warning about a type mismatch for the case that dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set:

drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma':
drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl);

This changes the driver to instead pass the physical address of the FIFO that is extracted from the MMIO resource, making the code more portable and avoiding the warning.

---
 drivers/mtd/nand/sh_flctl.c  | 5 +++--
 include/linux/mtd/sh_flctl.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/mtd/nand/sh_flctl.c +3 -2
index 57dc52578e07..0830a2d601e9 100644
@@ -160,7 +160,7 @@ static void flctl_setup_dma(struct sh_flctl *flctl)
 
 	memset(&cfg, 0, sizeof(cfg));
 	cfg.direction = DMA_MEM_TO_DEV;
-	cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl);
+	cfg.dst_addr = flctl->fifo;
 	cfg.src_addr = 0;
 	ret = dmaengine_slave_config(flctl->chan_fifo0_tx, &cfg);
 	if (ret < 0)
@@ -176,7 +176,7 @@ static void flctl_setup_dma(struct sh_flctl *flctl)
 
 	cfg.direction = DMA_DEV_TO_MEM;
 	cfg.dst_addr = 0;
-	cfg.src_addr = (dma_addr_t)FLDTFIFO(flctl);
+	cfg.src_addr = flctl->fifo;
 	ret = dmaengine_slave_config(flctl->chan_fifo0_rx, &cfg);
 	if (ret < 0)
 		goto err;
@@ -1095,6 +1095,7 @@ static int flctl_probe(struct platform_device *pdev)
 	flctl->reg = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(flctl->reg))
 		return PTR_ERR(flctl->reg);
+	flctl->fifo = res->start + 0x24; /* FLDTFIFO */
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
include/linux/mtd/sh_flctl.h +1 -0
index 1c28f8879b1c..067b37aff4a1 100644
@@ -148,6 +148,7 @@ struct sh_flctl {
 	struct platform_device	*pdev;
 	struct dev_pm_qos_request pm_qos;
 	void __iomem		*reg;
+	resource_size_t		fifo;
 
 	uint8_t	done_buff[2048 + 64];	/* max size 2048 + 64 */
 	int	read_bytes;
Signature · 1 line
2.1.0.rc2
#1 lore raw
Quoted 11 lines · Arnd Bergmann

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

Note that since the removal of (ARM) sh7367/sh7377/sh7372 support, this driver is used on SH only.

I'll send a patch to update Kconfig.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#2 lore raw
Quoted 13 lines · Geert Uytterhoeven
Quoted 11 lines · Arnd Bergmann

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

Quoted 2 lines

Note that since the removal of (ARM) sh7367/sh7377/sh7372 support, this driver is used on SH only.

It's still available as COMPILE_TEST, so it's still worth fixing.

But really, does anyone use this driver any more?

Brian

#3 lore raw

Hi Brian,

Quoted 14 lines · Brian Norris
Quoted 13 lines · Geert Uytterhoeven
Quoted 11 lines · Arnd Bergmann

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

Quoted 6 lines
Quoted 2 lines

Note that since the removal of (ARM) sh7367/sh7377/sh7372 support, this driver is used on SH only.

It's still available as COMPILE_TEST, so it's still worth fixing.

But really, does anyone use this driver any more?

It's used on the sh7723-based AP-325RXA board.
No idea if anyone is really using it.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#4 lore raw
Quoted 20 lines · On Thursday 10 December 2015 10:02:06 Geert Uytterhoeven wrote:
Quoted 17 lines · Brian Norris
Quoted 15 lines · Geert Uytterhoeven
Quoted 11 lines · Arnd Bergmann

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

Note that since the removal of (ARM) sh7367/sh7377/sh7372 support, this driver is used on SH only.

Quoted 6 lines
Quoted 3 lines

It's still available as COMPILE_TEST, so it's still worth fixing.

But really, does anyone use this driver any more?

It's used on the sh7723-based AP-325RXA board.
No idea if anyone is really using it.

If the question is about removing the driver, I think the answer then is that we should either remove the platform and the driver, or neither of them. sh7723 seems to be one of the more recent ones (added in 2009, only 7 of the 40 CPU subtypes are more recent, the last ones were added in 2012).

Arnd

Applied
#5 lore raw
In reply to Arnd Bergmann
Quoted 19 lines · Arnd Bergmann

By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping.

We also get a warning about a type mismatch for the case that dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set:

drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma':
drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl);

Quoted 5 lines

This changes the driver to instead pass the physical address of the FIFO that is extracted from the MMIO resource, making the code more portable and avoiding the warning.

Applied