[PATCH] mtd: sh_flctl: pass FIFO as physical address

[PATCH] mtd: sh_flctl: pass FIFO as physical address

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

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.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/mtd/nand/sh_flctl.c  | 5 +++--
 include/linux/mtd/sh_flctl.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 57dc52578e07..0830a2d601e9 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -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) {
diff --git a/include/linux/mtd/sh_flctl.h b/include/linux/mtd/sh_flctl.h
index 1c28f8879b1c..067b37aff4a1 100644
--- a/include/linux/mtd/sh_flctl.h
+++ b/include/linux/mtd/sh_flctl.h
@@ -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;
-- 
2.1.0.rc2

Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

[Geert Uytterhoeven]

On Tue, Dec 8, 2015 at 4:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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@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

Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

[Brian Norris]

On Tue, Dec 08, 2015 at 05:30:02PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 8, 2015 at 4:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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.

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

But really, does anyone use this driver any more?

Brian

Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

[Geert Uytterhoeven]

Hi Brian,

On Thu, Dec 10, 2015 at 3:21 AM, Brian Norris
<computersforpeace@gmail.com> wrote:
> On Tue, Dec 08, 2015 at 05:30:02PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Dec 8, 2015 at 4:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > 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.
>
> 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@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

Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

[Arnd Bergmann]

On Thursday 10 December 2015 10:02:06 Geert Uytterhoeven wrote:
> 
> On Thu, Dec 10, 2015 at 3:21 AM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Tue, Dec 08, 2015 at 05:30:02PM +0100, Geert Uytterhoeven wrote:
> >> On Tue, Dec 8, 2015 at 4:38 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > 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.
> >
> > 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

Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

[Brian Norris]

On Tue, Dec 08, 2015 at 04:38:12PM +0100, Arnd Bergmann wrote:
> 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.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied