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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Feb 2016 13:37:30 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Alexandre Courbot <acourbot@...dia.com>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	linux-mmc@...r.kernel.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org, gnurou@...il.com
Subject: Re: [PATCH] mmc: sdhci-tegra: Set DMA mask

On Wednesday 24 February 2016 18:11:19 Alexandre Courbot wrote:
> On T210, the sdhci controller can address more than 32 bits of address
> space. Failing to express this fact results in the use of bounce
> buffers and affects performance.
> 
> Signed-off-by: Alexandre Courbot <acourbot@...dia.com>
> ---
> I am pretty sure this one is wrong in some way, but just to get the ball
> rolling as the use of bounce buffers is currently quite heavy on Jetson TX1.
> 
> Thierry, Stephen, could you confirm that I got the DMA masks correctly? I
> am not sure about the actual addressable size on TX1, and also suspect TK1 can
> also address more than 32 bits.
> 
> Also, I noticed that sdhci_host has a dma_mask member which I thought would do
> the trick but actually doesn't seem to be used for anything useful. Could the
> MMC maintainers comment on this and let me know if the DMA mask setting should
> be moved at the core level instead of being done per-driver?

So the question is what the DMA capabilities of the sdhci device are.

Usually I think SDHCI should just support a 64-bit mask, and you can
request that in the driver, but the platform might reject it, e.g.
if the parent bus is lacking a dma-ranges property.

On 32-bit platforms with no RAM above the 4GB boundary, setting a 64-bit
mask typically succeeds, because there is no harm in using it.

You should only set a 34-bit mask in the specific case that:

* SDHCI reports that it supports 64-bit addressing
* The parent bus supports 64-bit addressing and correctly sets up
  its dma-ranges property
* The device is connected incorrectly to the parent bus and
  any access above 0x400000000ull fail to end up in the correct
  memory for this particular device, but not other devices on the
  same bus.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ