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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Dec 2015 10:27:25 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Brian Norris <computersforpeace@...il.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Simon Horman <horms@...ge.net.au>,
	MTD Maling List <linux-mtd@...ts.infradead.org>,
	Frans Klaver <fransklaver@...il.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] mtd: sh_flctl: pass FIFO as physical address

On Thursday 10 December 2015 10:02:06 Geert Uytterhoeven wrote:
> 
> On Thu, Dec 10, 2015 at 3:21 AM, Brian Norris
> <computersforpeace@...il.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@...db.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/