linux-kernel - Re: [PATCH 00/04] PCI: rcar: Driver model and physical address space update

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:	Wed, 12 Feb 2014 13:59:11 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	linux-pci@...r.kernel.org, linux-sh@...r.kernel.org,
	linux-kernel@...r.kernel.org, valentine.barshak@...entembedded.com,
	horms@...ge.net.au, ben.dooks@...ethink.co.uk
Subject: Re: [PATCH 00/04] PCI: rcar: Driver model and physical address space
 update

On Wed, Feb 05, 2014 at 03:52:43PM +0900, Magnus Damm wrote:
> PCI: rcar: Driver model and physical address space update
> 
> [PATCH 01/04] PCI: rcar: Register each instance independently
> [PATCH 02/04] PCI: rcar: Break out window size handling
> [PATCH 03/04] PCI: rcar: Add DMABOUNCE support
> [PATCH 04/04] PCI: rcar: Enable BOUNCE in case of HIGHMEM
> 
> These patches update the pci-rcar-gen2.c driver in various ways
> including cleanups for driver model interface (1/4), readability
> update (2/4) and also bounce buffer support (3/4, 4/4). Basically
> the first two are just cleanups and the rest are fixes.
> 
> As it is today without these patches the system memory start address
> is hard coded at 0x4000000 and the window is fixed at 1GiB. So we
> have board specific code hidden in the driver which is good to avoid.
> 
> With these hard coded board specific constants there are some error cases
> that are not handled, in particular the issue that only maximum 1GiB of
> physical address space can be used for bus mastering with a single window.
> The common case of using ARM CONFIG_VMSPLIT_3G results in no visible issues
> as long as CONFIG_BOUNCE is used, but other CONFIG_VMSPLIT settings will
> break due to the hard coded 1GiB window not being enough. It has been
> verified that reducing the window size to 256MB makes the driver behave
> the same with VMSPLIT_3G as 1GiB window size and other VMSPLIT settings.
> 
> To handle the maximum 1GiB physical address space limitation two types
> of bounce buffers are added. The ARM specific DMABOUNCE code is in 3/4
> hooked up to a chunk of local memory that is also handed of as coherent
> memory to the pci devices hanging off the PCI bridge. The driver makes
> sure to set the window so the local memory is always included. When the
> PCI devices are operating and in case memory is used outside the window
> then the DMABOUNCE buffers kicks in. This makes the driver support all
> kinds of VMSPLIT settings and window sizes. The BOUNCE code in 4/4 is
> selected to make sure bounce buffers are used for HIGHMEM.
> 
> With these patches this driver can be used with or without CMA and
> with or without DMA zone. Basically the system wide memory setup is
> left to the user. If a DMA zone is used then the PCI window will
> be setup to cover that. Same thing with CMA.
> 
> Tested with USB storage using LPAE and various VMSPLIT settings together
> with renesas git tag renesas-devel-v3.14-rc1-20140204 from kernel.org
> 
> Signed-off-by: Magnus Damm <damm@...nsource.se>
> ---
> 
>  Written against renesas.git tag renesas-devel-v3.14-rc1-20140204
> 
>  drivers/pci/host/Kconfig         |    3 
>  drivers/pci/host/pci-rcar-gen2.c |  367 +++++++++++++++++++++++++++++++-------
>  2 files changed, 306 insertions(+), 64 deletions(-)

Simon, if you want to ack these, I'll be happy to merge them for v3.15.
I'm not really qualified to review them myself.

Bjorn
--
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/