Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Russell King - ARM Linux]

Do you think that the appropriate patches could be copied to the
appropriate people please?

On Thu, Jan 11, 2018 at 04:46:24PM -0800, Dan Williams wrote:
> Changes since v1 [1]:
> * fixup the ifence definition to use alternative_2 per recent AMD
>   changes in tip/x86/pti (Tom)
> 
> * drop 'nospec_ptr' (Linus, Mark)
> 
> * rename 'nospec_array_ptr' to 'array_ptr' (Alexei)
> 
> * rename 'nospec_barrier' to 'ifence' (Peter, Ingo)
> 
> * clean up occasions of 'variable assignment in if()' (Sergei, Stephen)
> 
> * make 'array_ptr' use a mask instead of an architectural ifence by
>   default (Linus, Alexei)
> 
> * provide a command line and compile-time opt-in to the ifence
>   mechanism, if an architecture provides 'ifence_array_ptr'.
> 
> * provide an optimized mask generation helper, 'array_ptr_mask', for
>   x86 (Linus)
> 
> * move 'get_user' hardening from '__range_not_ok' to '__uaccess_begin'
>   (Linus)
> 
> * drop "Thermal/int340x: prevent bounds-check..." since userspace does
>   not have arbitrary control over the 'trip' index (Srinivas)
> 
> * update the changelog of "net: mpls: prevent bounds-check..." and keep
>   it in the series to continue the debate about Spectre hygiene patches.
>   (Eric).
> 
> * record a reviewed-by from Laurent on "[media] uvcvideo: prevent
>   bounds-check..."
> 
> * update the cover letter
> 
> [1]: https://lwn.net/Articles/743376/
> 
> ---
> 
> Quoting Mark's original RFC:
> 
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [2]
> and the Documentation patch in this series."
> 
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
> mitigation, '__array_ptr', uses a 'mask' approach that removes
> conditional branches instructions, and otherwise aims to redirect
> speculation to use a NULL pointer rather than a user controlled value.
> 
> The mask is generated by the following from Alexei, and Linus:
> 
> mask = ~(long)(_i | (_s - 1 - _i)) >> (BITS_PER_LONG - 1);
> 
> ...and Linus provided an optimized mask generation helper for x86:
> 
> asm ("cmpq %1,%2; sbbq %0,%0;"
>   :"=r" (mask)
>   :"r"(sz),"r" (idx)
>   :"cc");
> 
> The 'array_ptr' mechanism can be switched between 'mask' and 'ifence'
> via the spectre_v1={mask,ifence} command line option, and the
> compile-time default is set by selecting either CONFIG_SPECTRE1_MASK or
> CONFIG_SPECTRE1_IFENCE.
> 
> The 'array_ptr' infrastructure is the primary focus this patch set. The
> individual patches that perform 'array_ptr' conversions are a point in
> time (i.e. earlier kernel, early analysis tooling, x86 only etc...)
> start at finding some of these gadgets.
> 
> Another consideration for reviewing these patches is the 'hygiene'
> argument. When a patch refers to hygiene it is concerned with stopping
> speculation on an unconstrained or insufficiently constrained pointer
> value under userspace control. That by itself is not sufficient for
> attack (per current understanding) [3], but it is a necessary
> pre-condition.  So 'hygiene' refers to cleaning up those suspect
> pointers regardless of whether they are usable as a gadget.
> 
> These patches are also be available via the 'nospec-v2' git branch
> here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v2
> 
> Note that the BPF fix for Spectre variant1 is merged in the bpf.git
> tree [4], and is not included in this branch.
> 
> [2]: 
> https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
> [3]: https://spectreattack.com/spectre.pdf
> [4]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc98
> 
> ---
> 
> Dan Williams (16):
>   x86: implement ifence()
>   x86: implement ifence_array_ptr() and array_ptr_mask()
>   asm-generic/barrier: mask speculative execution flows
>   x86: introduce __uaccess_begin_nospec and ASM_IFENCE
>   x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths
>   ipv6: prevent bounds-check bypass via speculative execution
>   ipv4: prevent bounds-check bypass via speculative execution
>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>   userns: prevent bounds-check bypass via speculative execution
>   udf: prevent bounds-check bypass via speculative execution
>   [media] uvcvideo: prevent bounds-check bypass via speculative execution
>   carl9170: prevent bounds-check bypass via speculative execution
>   p54: prevent bounds-check bypass via speculative execution
>   qla2xxx: prevent bounds-check bypass via speculative execution
>   

[PATCH 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of 
declaration
drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of 
struct-union-enum-specifier
drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface
drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of 
type declaration
drivers/net/ethernet/cadence/macb.h:877:1: sparse: got }
In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name 
'phy_interface_t'
 phy_interface_t  phy_interface;
 ^~~

Add linux/phy.h to macb.h

Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
---
 drivers/net/ethernet/cadence/macb.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index d67adad67be1..383da8cf5f6d 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -10,6 +10,8 @@
 #ifndef _MACB_H
 #define _MACB_H
 
+#include 
+
 #define MACB_GREGS_NBR 16
 #define MACB_GREGS_VERSION 2
 #define MACB_MAX_QUEUES 8
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

[Russell King - ARM Linux]

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote:
> The various 5380 drivers inconsistently store register pointers
> either in the Scsi_Host struct "legacy crap" area or in special,
> board-specific members of the NCR5380_hostdata struct. Uniform
> use of the latter struct makes for simpler and faster code (see
> the following patches) and helps to reduce use of the
> NCR5380_implementation_fields macro.
> 
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>
> Reviewed-by: Hannes Reinecke <h...@suse.com>
> Tested-by: Ondrej Zary <li...@rainbow-software.org>
> Tested-by: Michael Schmitz <schmitz...@gmail.com>
> ---
>  drivers/scsi/arm/cumana_1.c | 60 
>  drivers/scsi/arm/oak.c  | 23 

For these two,

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/12] scsi/ncr5380: Use correct types for device register accessors

[Russell King - ARM Linux]

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote:
> For timeout values adopt unsigned long, which is the type of jiffies etc.
> 
> For chip register values and bit masks pass u8, which is the return type
> of readb, inb etc.
> 
> For device register offsets adopt unsigned int, as it is suitable for
> adding to base addresses.
> 
> Pass the NCR5380_hostdata pointer to the board-specific routines instead
> of the Scsi_Host pointer. The board-specific code is concerned with
> hardware and not with SCSI protocol or the mid-layer.
> 
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>
> Reviewed-by: Hannes Reinecke <h...@suse.com>
> Tested-by: Ondrej Zary <li...@rainbow-software.org>
> Tested-by: Michael Schmitz <schmitz...@gmail.com>
> ---
>  drivers/scsi/arm/cumana_1.c | 20 +++-----
>  drivers/scsi/arm/oak.c  |  6 ++

For these two:

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

[Russell King - ARM Linux]

On Mon, Oct 10, 2016 at 12:46:52AM -0400, Finn Thain wrote:
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>
> Reviewed-by: Hannes Reinecke <h...@suse.com>

Thanks.

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 10/12] scsi/ncr5380: Expedite register polling

[Russell King - ARM Linux]

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote:
> Avoid the call to NCR5380_poll_politely2() when possible. The call is
> easily short-circuited on the PIO fast path, using the inline wrapper.
> This requires that the NCR5380_read macro be made available before
> any #include "NCR5380.h" so a few declarations have to be moved too.
> 
> Signed-off-by: Finn Thain 
> Reviewed-by: Hannes Reinecke 
> Tested-by: Ondrej Zary 
> Tested-by: Michael Schmitz 
> ---

> diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
> index ae1d4c6..fb7600d 100644
> --- a/drivers/scsi/arm/cumana_1.c
> +++ b/drivers/scsi/arm/cumana_1.c
> @@ -29,6 +29,10 @@
>  #define NCR5380_implementation_fields\
>   unsigned ctrl
>  
> +struct NCR5380_hostdata;
> +static u8 cumanascsi_read(struct NCR5380_hostdata *, unsigned int);
> +static void cumanascsi_write(struct NCR5380_hostdata *, unsigned int, u8);
> +
>  #include "../NCR5380.h"
>  
>  #define CTRL 0x16fc

This seems to be non-obviously unrelated to this commit - should it be in
some other commit?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/12] scsi/ncr5380: Use correct types for DMA routines

[Russell King - ARM Linux]

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote:
> Apply prototypes to get consistent function signatures for the DMA
> functions implemented in the board-specific drivers. To avoid using
> macros to alter actual parameters, some of those functions are reworked
> slightly.
> 
> This is a step toward the goal of passing the board-specific routines
> to the core driver using an ops struct (as in a platform driver or
> library module).
> 
> This also helps fix some inconsistent types: where the core driver uses
> ints (cmd->SCp.this_residual and hostdata->dma_len) for keeping track of
> transfers, certain board-specific routines used unsigned long.
> 
> While we are fixing these function signatures, pass the hostdata pointer
> to DMA routines instead of a Scsi_Host pointer, for shorter and faster
> code.
> 
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>
> Reviewed-by: Hannes Reinecke <h...@suse.com>
> Tested-by: Ondrej Zary <li...@rainbow-software.org>
> Tested-by: Michael Schmitz <schmitz...@gmail.com>
> ---
>  drivers/scsi/arm/cumana_1.c | 26 ++--
>  drivers/scsi/arm/oak.c  | 13 

For these two,

Acked-by: Russell King <rmk+ker...@armlinux.org.uk>

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH, resend] scsi: advansys: fix big-endian builds

[Russell King - ARM Linux]

On Mon, Nov 16, 2015 at 05:49:23PM +0100, Arnd Bergmann wrote:
> It turns out that the commit that introduced this used the cpu_to_le32()
> incorrectly on an 8-bit field, which results in the sense_len to always
> be set to zero, as the SCSI_SENSE_BUFFERSIZE value gets moved to upper
> byte of the 32-bit intermediate.

More people need to run the sparse checker with -D__CHECK_ENDIAN__ and
have proper endian annotations?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 12:31:16PM -0400, Tejun Heo wrote:
 On Wed, Apr 01, 2015 at 12:13:36PM -0400, Tejun Heo wrote:
   Signed-off-by : Suman Tripathi stripa...@apm.com
  
  Applied to libata/for-4.1 w/ minor edit.
 
 Reverted due to build failure from missing asm/cputype.h.

I'm guessing this is some kind of ARM driver, which is why
linux-arm-kernel has been Cc'd - though I haven't seen the original
patch.

ARM has asm/cputype.h, and has had for a long time, so missing
asm/cputype.h doesn't make sense as a reason to revert it.  Maybe
it's trying to be built on x86 when it should be restricted to
only ARM?

Dunno without seeing the original patch.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC

[Russell King - ARM Linux]

On Wed, Apr 01, 2015 at 06:00:33PM +0100, Catalin Marinas wrote:
 On Wed, Apr 01, 2015 at 05:39:56PM +0100, Russell King - ARM Linux wrote:
  On Wed, Apr 01, 2015 at 12:31:16PM -0400, Tejun Heo wrote:
   On Wed, Apr 01, 2015 at 12:13:36PM -0400, Tejun Heo wrote:
 Signed-off-by : Suman Tripathi stripa...@apm.com

Applied to libata/for-4.1 w/ minor edit.
   
   Reverted due to build failure from missing asm/cputype.h.
  
  I'm guessing this is some kind of ARM driver, which is why
  linux-arm-kernel has been Cc'd - though I haven't seen the original
  patch.
  
  ARM has asm/cputype.h, and has had for a long time, so missing
  asm/cputype.h doesn't make sense as a reason to revert it.  Maybe
  it's trying to be built on x86 when it should be restricted to
  only ARM?
  
  Dunno without seeing the original patch.
 
 First search result leads here:
 
 https://www.mail-archive.com/devicetree@vger.kernel.org/msg67774.html

Thanks.

 The driver in general should not be ARM specific, though it runs on an
 ARMv8 platform. But looking at the patch it has some errata workarounds
 triggered based on the CPU id (MIDR). That looks dodgy as it doesn't
 even check the full ID, only the variant part.

Okay, it's not ARM but an ARM64 driver, so that's your territory, not
mine. :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: arm: cumana_1.c: Remove unused function

[Russell King - ARM Linux]

On Sat, Dec 20, 2014 at 08:50:45AM -0800, Jeremiah Mahler wrote:
 On Sat, Dec 20, 2014 at 05:36:15PM +0100, Rickard Strandqvist wrote:
  Remove the function cumanascsi_setup() that is not used anywhere.
  
  This was partially found by using a static code analysis program called 
  cppcheck.
  
  Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se

 You can blame Linus for this one :-)
 
 ~/linux-next$ git blame -L 38,40 drivers/scsi/arm/cumana_1.c 
 ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 38) void
 cumanascsi_setup(char *str, int *ints)
 ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 39) {
 ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 40) }
 ~/linux-next$

Great, that gets me off the hook :)

Acked-by: Russell King rmk+ker...@arm.linux.org.uk

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: arm: cumana_1.c: Remove unused function

[Russell King - ARM Linux]

On Sat, Dec 20, 2014 at 09:35:53AM -0800, James Bottomley wrote:
 On Sat, 2014-12-20 at 16:58 +, Russell King - ARM Linux wrote:
  On Sat, Dec 20, 2014 at 08:50:45AM -0800, Jeremiah Mahler wrote:
   On Sat, Dec 20, 2014 at 05:36:15PM +0100, Rickard Strandqvist wrote:
Remove the function cumanascsi_setup() that is not used anywhere.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
rickard_strandqv...@spectrumdigital.se
  
   You can blame Linus for this one :-)
   
   ~/linux-next$ git blame -L 38,40 drivers/scsi/arm/cumana_1.c 
   ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 38) void
   cumanascsi_setup(char *str, int *ints)
   ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 39) {
   ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 40) }
   ~/linux-next$
  
  Great, that gets me off the hook :)
 
 Well, no, it doesn't: 1da177e is the git tree root commit which was
 created by importing the existing bitkeeper version 2.6.12-rc2 into git.
 It means this code predates the git import.  You might be able to chase
 it through the history tree if you want, but that only goes back as far
 as bitkeeper history.

James, please see the smilie on the end of the comment, I wasn't being
serious.  Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ahci_xgene: Fix the error print invalid resource for APM X-Gene SoC AHCI SATA Host Controller driver.

[Russell King - ARM Linux]

On Mon, Sep 15, 2014 at 04:44:52PM +0900, Tejun Heo wrote:
 On Mon, Sep 15, 2014 at 01:10:01PM +0530, Suman Tripathi wrote:
  [suman] : So the posted version is acceptable ? Any others comments on this
  patch ?
 
 I'm suggesting setting ctx-cs_mux to NULL on failure.  IOW,
 
   if (res) {
   ctx-csr_mux = devm_ioremap_resources();
   if (IS_ERR(ctx-csr_mux)) {
   print warning or something;
   ctx-csr_mux = NULL;
   }
   }

A much better approach is:

if (res) {
void __iomem *csr = devm_ioremap_resources();
if (IS_ERR(csr)) {
ret = ERR_PTR(csr);
dev_xxx();
goto err;
}

ctx-csr_mux = csr;
}

Then you never end up in the situation where csr_mux contains an error
pointer value - and is much more obvious that is the case.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] acornscsi: remove linked command support

[Russell King - ARM Linux]

On Wed, May 28, 2014 at 06:26:44PM +0400, James Bottomley wrote:
 On Wed, 2014-05-28 at 03:41 -0700, Christoph Hellwig wrote:
  Looks good,
  
  Reviewed-by: Christoph Hellwig h...@lst.de
  
  And I have to disagree with James here, removing code that isn't even
  compiled always is an improvement, especially for an unmaintained
  driver.
 
 Well, as I said, this is in theory a maintained driver, so just get an
 ack from Russell and this debate is moot.

I don't see any harm in removing this - I don't think I've owned any
SCSI devices which supported linked commands, which is why I never
put much effort into it.  As no one else seems to care about it (given
the number of years it's been left alone), removing the linked command
stuff is fine.

Acked-by: Russell King rmk+ker...@arm.linux.org.uk

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

[Russell King - ARM Linux]

On Sat, Mar 22, 2014 at 03:59:11PM -0700, James Bottomley wrote:
 On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote:
  And I'm disagreeing with that statement which implies that it's something
  that is an architecture wide property for any particular architecture.
  
  Right now in mainline, if ARM has IOMMU support enabled, then SG_CHAIN
  support will also be enabled.  I've a patch out of tree which I've been
  using for years which enables SG_CHAIN for a particular SoC (Dove).
  Otherwise, it doesn't have support for SG_CHAIN.
  
  PARISC on the other hand (as you list) has no support to enable SG_CHAIN
  under any circumstances.
  
  Where we're disagreeing is whether this is something that is always-on or
  always-off for any particular architecture.
 
 Actually, I don't disagree with that.  PA used to share sb_iommu with
 ia64 (it's the same chipset for the HP versions), but we can't now
 because ia64 is chained and we're not and there's no way to say chained
 for this platform but not for these other more legacy ones.  If you have
 a proposal for this, I'd be interested, so I don't have to do an all or
 nothing conversion, but the config option isn't it because our platform
 configuration is runtime determined (we usually select every driver and
 let the actual one be chosen at runtime from the config table).

At runtime, it's obviously a lot harder to resolve.  However, that's not
what we're trying to do with this patch.

The main issue is that Laura is trying to add SG chain support to ARM64.
At the moment, ARM64 uses the asm-generic version of scatterlist.h
directly.

Her first spin of the patch involved creating
arch/arm64/include/asm/scatterlist.h, which was nothing more than an
include of the asm-generic header file of the same name, and the
definition of ARCH_HAS_SG_CHAIN.  That seemed to be extremely wasteful
and sub-optimal way to handle this.

Moving this symbol into the Kconfig means that ARM64 no longer has to
have this additional file (and probably a bunch of other architectures
fall into that same camp) and the ARM specific CONFIG_ARM_HAS_SG_CHAIN
can be eliminated in favour of the now generic cross-arch config symbol.

We have plenty of other Kconfig symbols which control similar features
throughout the kernel source, there is no reason that this one should
not be the same.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

[Russell King - ARM Linux]

On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
 Perhaps now might be the time to ask which are the remaining
 architectures that cannot do SG chaining and then we can fix them and
 pull the whole thing out.

Not quite.  You're making the assumption that we can be sure that all
the scatterlist users on an architecture have been converted - that's
simply not true on ARM.  We have some which have, and some which still
have not been audited.

The cases that get us here would be old platform DMA code which walks
scatterlists handed to it from drivers - stuff like
arch/arm/mach-rpc/dma.c (which probably can cope), and drivers/scsi/arm/*
(which definitely can't because of their SCSI pointers save/restore
handling message.)  I know that's one case where SG_CHAIN definitely
isn't supported on ARM.

So, we had decided not to enable it, but this means that new stuff
isn't benefitting from this.  I've recently asked arm-soc to enable
it for the modern multi-platform builds, because modern stuff really
be written with correct SG chaining in mind.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

[Russell King - ARM Linux]

On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
 On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
  On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
   Perhaps now might be the time to ask which are the remaining
   architectures that cannot do SG chaining and then we can fix them and
   pull the whole thing out.
  
  Not quite.  You're making the assumption that we can be sure that all
  the scatterlist users on an architecture have been converted - that's
  simply not true on ARM.
 
 No I'm not, I said now might be the time to ask which are the remaining
 architectures that cannot do SG chaining

And I'm disagreeing with that statement which implies that it's something
that is an architecture wide property for any particular architecture.

Right now in mainline, if ARM has IOMMU support enabled, then SG_CHAIN
support will also be enabled.  I've a patch out of tree which I've been
using for years which enables SG_CHAIN for a particular SoC (Dove).
Otherwise, it doesn't have support for SG_CHAIN.

PARISC on the other hand (as you list) has no support to enable SG_CHAIN
under any circumstances.

Where we're disagreeing is whether this is something that is always-on or
always-off for any particular architecture.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM fixes

[Russell King - ARM Linux]

On Tue, Feb 18, 2014 at 03:49:03PM -0800, Linus Torvalds wrote:
 On Mon, Feb 17, 2014 at 3:46 PM, Russell King r...@arm.linux.org.uk wrote:
 
  One fix touches code outside of arch/arm, which is related to sorting
  out the DMA masks correctly.  There is a long standing issue with the
  conversion from PFNs to addresses where people assume that shifting an
  unsigned long left by PAGE_SHIFT results in a correct address.
 
 You should probably have used PFN_PHYS(), which does this correctly.
 Your explicit u64 isn't exactly wrong, but phys_addr_t is really the
 right type for the result.

Almost, but not quite.  If we're going to avoid u64, then dma_addr_t
woudl be the right type here because we're talking about DMA addresses.
We could also switch to keeping this as PFNs - block internally converts
it to a PFN anyway:

void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
{
unsigned long b_pfn = max_addr  PAGE_SHIFT;
...

and that is ultimately assigned to q-limits.bounce_pfn.  So, if we
arranged for blk_queue_bounce_limit() to take a PFN, and then modified
it's two callers, then we don't need to care about converting between
phys and pfns.

Maybe blk_queue_bounce_pfn_limit() so we ensure all users get caught?

 That said, it's admittedly a disgusting name, and I wonder if we
 should introduce a nicer-named pfn_to_phys() that matches the other
 xyz_to_abc() functions we have (including pfn_to_virt())

We have these on ARM:

arch/arm/include/asm/memory.h:#define   __pfn_to_phys(pfn)  
((phys_addr_t)(pfn)  PAGE_SHIFT)
arch/arm/include/asm/memory.h:#define   __phys_to_pfn(paddr)((unsigned 
long)((paddr)  PAGE_SHIFT))

it probably makes sense to pick those right out, maybe losing the
__ prefix on them.

 Looking at it, the Xen people then do this disgusting thing:
 __va(PFN_PHYS(pfn)) which is both ugly and pointless (__va() isn't
 going to work for a phys_addr_t anyway). And linux/mm.h has this
 gem:
 
   __va(PFN_PHYS(page_to_pfn(page)));

Wow.  Two things spring to mind there... highmem pages, and don't we
already have page_address() for that?

 Anyway, I pulled your change to scsi_lib.c, since it's certainly no
 worse than what we used to have, but James and company cc'd too.

Thanks.  I do worry about all the other places which I also found -
but the first step is getting concensus on what the macro should be.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

[Russell King - ARM Linux]

On Thu, Feb 13, 2014 at 08:01:12PM +, Russell King - ARM Linux wrote:
 On Thu, Feb 13, 2014 at 10:07:01AM -0800, James Bottomley wrote:
  On Thu, 2014-02-13 at 17:11 +, Russell King - ARM Linux wrote:
   On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote:
This doesn't really look like the right fix.  You replaced dev-dma_mask
with a calculation on dev_max_pfn().  Since dev-dma_mask is always u64
and dev_max_pfn is supposed to be returning the pfn of the dma_mask, it
should unconditionally be 64 bits as well.  Either that or it should
return dma_addr_t.
   
   My reasoning is that PFNs in the system are always of type unsigned long
   and therefore a function returning a pfn should have that type.  If we
   overflow a PFN fitting in an unsigned long, we have lots of places which
   need fixing.
  
  It's not intuitive to people who need the dma mask that they're supposed
  to use dma_max_pfn()  PAGE_SHIFT but now they have to worry about the
  casting and, if they don't get it right, nothing will warn or tell them.
  what about a new macro, say dma_max_mask(dev) that just returns
  (u64)dma_max_pfn()  PAGE_SHIFT?
 
 This sounds like a good idea.
 
 I've just been looking at places which do this  PAGE_SHIFT, and we
 have other places which suffer from this same bug all over the kernel,
 so maybe we actually need a pfn_to_addr() macro or similar so that
 people get this right in these other places too?  It appears to be
 quite a widespread problem.
 
 I'm surprised none of the below haven't already caused a problem.
 
 Thoughts?

Okay, as there's been no response to this, I'm going to push the patch
as-is to Linus this evening.

Nevertheless, your point is valid, but it is more of a general problem in
the kernel than with this specific change - and it's more important to fix
the existing problem here than to try and work out a new way of sorting
this out to fix the general case in the middle of the -rc series.

It is arguable that people _should_ know that shifting an unsigned long
left and assigning it to a u64 doesn't automatically get any of the high
bits set - the promotion happens at assignment, not while the expression
is being evaluated.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

[Russell King - ARM Linux]

On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote:
 This doesn't really look like the right fix.  You replaced dev-dma_mask
 with a calculation on dev_max_pfn().  Since dev-dma_mask is always u64
 and dev_max_pfn is supposed to be returning the pfn of the dma_mask, it
 should unconditionally be 64 bits as well.  Either that or it should
 return dma_addr_t.

My reasoning is that PFNs in the system are always of type unsigned long
and therefore a function returning a pfn should have that type.  If we
overflow a PFN fitting in an unsigned long, we have lots of places which
need fixing.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

[Russell King - ARM Linux]

On Thu, Feb 13, 2014 at 10:07:01AM -0800, James Bottomley wrote:
 On Thu, 2014-02-13 at 17:11 +, Russell King - ARM Linux wrote:
  On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote:
   This doesn't really look like the right fix.  You replaced dev-dma_mask
   with a calculation on dev_max_pfn().  Since dev-dma_mask is always u64
   and dev_max_pfn is supposed to be returning the pfn of the dma_mask, it
   should unconditionally be 64 bits as well.  Either that or it should
   return dma_addr_t.
  
  My reasoning is that PFNs in the system are always of type unsigned long
  and therefore a function returning a pfn should have that type.  If we
  overflow a PFN fitting in an unsigned long, we have lots of places which
  need fixing.
 
 It's not intuitive to people who need the dma mask that they're supposed
 to use dma_max_pfn()  PAGE_SHIFT but now they have to worry about the
 casting and, if they don't get it right, nothing will warn or tell them.
 what about a new macro, say dma_max_mask(dev) that just returns
 (u64)dma_max_pfn()  PAGE_SHIFT?

This sounds like a good idea.

I've just been looking at places which do this  PAGE_SHIFT, and we
have other places which suffer from this same bug all over the kernel,
so maybe we actually need a pfn_to_addr() macro or similar so that
people get this right in these other places too?  It appears to be
quite a widespread problem.

I'm surprised none of the below haven't already caused a problem.

Thoughts?

int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
 unsigned long nr_pages)
{
resource_size_t start, size;

start = phys_start_pfn  PAGE_SHIFT;

void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
unsigned long start_pfn, enum memmap_context context)
{
unsigned long end_pfn = start_pfn + size;
unsigned long pfn;

/* The shift won't overflow because ZONE_NORMAL is below 4G. */
if (!is_highmem_idx(zone))
set_page_address(page, __va(pfn  PAGE_SHIFT));

void __init free_area_init_nodes(unsigned long *max_zone_pfn)
{
unsigned long start_pfn, end_pfn;

for_each_mem_pfn_range(i, MAX_NUMNODES, start_pfn, end_pfn, nid)
printk(  node %3d: [mem %#010lx-%#010lx]\n, nid,
   start_pfn  PAGE_SHIFT, (end_pfn  PAGE_SHIFT) - 1);
(thankfully, this one is just a printk).

int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
   struct vm_area_struct **res_vma, dma_addr_t *res_pa)
{
unsigned long this_pfn, prev_pfn;
dma_addr_t pa = 0;

if (prev_pfn == 0)
pa = this_pfn  PAGE_SHIFT;

static pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 unsigned long size, pgprot_t vma_prot)
{
#ifdef pgprot_noncached
phys_addr_t offset = pfn  PAGE_SHIFT;

if (uncached_access(file, offset))
return pgprot_noncached(vma_prot);
#endif
return vma_prot;

static int i810_insert_dcache_entries(struct agp_memory *mem, off_t pg_start,
  int type)
{
int i;

for (i = pg_start; i  (pg_start + mem-page_count); i++) {
dma_addr_t addr = i  PAGE_SHIFT;


-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

[Russell King]

We must use a 64-bit for this, otherwise overflowed bits get lost, and
that can result in a lower than intended value set.

Fixes: 8e0cb8a1f6ac (ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for 
bounce_limit calculations)
Fixes: 7d35496dd982 (ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for 
bounce_limit calculations)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
While poking about with the Cubox-i4 and investigating why my UHS-1
SD card wasn't achieving its full potential, I came across a slight
problem... the SDHCI host sets a mask of 0x, but with the
start of memory at pfn 0x1, the blk code sees this when setting
the bounce limit:

max addr 0x0000 bounce limit 0x dma 1

and this results in the bounce functions appearing in the profile:

c00f8b70 copy_to_high_bio_irq  1139 2.5886
c00f8d28 bounce_end_io   12 0.0714
c00f8dd0 bounce_end_io_read_isa   8 0.1053

which, compared to the cost of copying the data to userland and
request handling, this is quite significant:

c04b1794 sdhci_request  268 0.5447
c02d0740 __copy_to_user_std 398 0.4252

With this calculation fixed, we avoid the bouncing code entirely.

max addr 0x10000 bounce limit 0x10 dma 0

 drivers/mmc/card/queue.c | 2 +-
 drivers/scsi/scsi_lib.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 357bbc54fe4b..3e049c13429c 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -197,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card,
struct mmc_queue_req *mqrq_prev = mq-mqrq[1];
 
if (mmc_dev(host)-dma_mask  *mmc_dev(host)-dma_mask)
-   limit = dma_max_pfn(mmc_dev(host))  PAGE_SHIFT;
+   limit = (u64)dma_max_pfn(mmc_dev(host))  PAGE_SHIFT;
 
mq-card = card;
mq-queue = blk_init_queue(mmc_request_fn, lock);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7bd7f0d5f050..62ec84b42e31 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1684,7 +1684,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
host_dev = scsi_get_device(shost);
if (host_dev  host_dev-dma_mask)
-   bounce_limit = dma_max_pfn(host_dev)  PAGE_SHIFT;
+   bounce_limit = (u64)dma_max_pfn(host_dev)  PAGE_SHIFT;
 
return bounce_limit;
 }
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King - ARM Linux]

On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
 Hi Russell,
 
 Em Mon, 30 Sep 2013 13:57:47 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  On 09/19/2013 11:44 PM, Russell King wrote:
   Replace the following sequence:
   
 dma_set_mask(dev, mask);
 dma_set_coherent_mask(dev, mask);
   
   with a call to the new helper dma_set_mask_and_coherent().
   
   Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
  
  Acked-by: Hans Verkuil hans.verk...@cisco.com
 
 Somehow, I lost your original post (I got unsubscribed on a few days 
 from all vger mailing lists at the end of september).
 
 I suspect that you want to sent this via your tree, right?

Yes please.

 If so:
 
 Acked-by: Mauro Carvalho Chehab m.che...@samsung.com

Added, thanks.

   - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
   - if (err)
   - return -ENODEV;
   - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
   + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
 if (err)
 return -ENODEV;

One thing I've just noticed is that return should be return err not
return -ENODEV - are you okay for me to change that in this patch?

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/51] DMA mask changes

[Russell King - ARM Linux]

On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk:
  This email is only being sent to the mailing lists in question, not to
  anyone personally.  The list of individuals is far to great to do that.
  I'm hoping no mailing lists reject the patches based on the number of
  recipients.
 
 Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
 [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
 [PATCH 14/51] DMA-API: net: b43: (...)
 [PATCH 15/51] DMA-API: net: b43legacy: (...)
 ;)
 
 I believe Joe has some nice script for doing it that way. When fixing
 some coding style / formatting, he sends only related patches to the
 given ML.

If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.

Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

[Russell King - ARM Linux]

On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
 On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
  register_platform_device_full() can setup the DMA mask provided the
  appropriate member is set in struct platform_device_info.  So lets
  make that be the case.  This avoids a direct reference to the DMA
  masks by this driver.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Acked-by: Vinod Koul vinod.k...@intel.com
 
 This also brings me question that should we force the driver to use the
 dma_set_mask_and_coherent() API or they have below flexiblity too?

There's two issues here:
1. dma_set_mask_and_coherent() will only work if dev-dma_mask points at
   some storage for the mask.  This needs to have .dma_mask in the
   platform_device_info initialised.

2. Yes, this driver should also be calling the appropriate DMA mask setting
   functions in addition to having the mask initialized at device creation
   time.

Here's a replacement patch, though maybe it would be better to roll all
the additions of dma_set_mask_and_coherent() in drivers/dma into one
patch?  In other words, combine the addition of this with these two
patches:

dma: pl330: add dma_set_mask_and_coherent() call
dma: pl08x: add dma_set_mask_and_coherent() call

8=
From: Russell King rmk+ker...@arm.linux.org.uk
Subject: [PATCH] DMA-API: dma: edma.c: no need to explicitly initialize DMA
 masks

register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info.  So lets
make that be the case.  This avoids a direct reference to the DMA
masks by this driver.

While here, add the dma_set_mask_and_coherent() call which the DMA API
requires DMA-using drivers to call.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/edma.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..fd5e48c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -631,6 +631,10 @@ static int edma_probe(struct platform_device *pdev)
struct edma_cc *ecc;
int ret;
 
+   ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+
ecc = devm_kzalloc(pdev-dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
dev_err(pdev-dev, Can't allocate controller\n);
@@ -702,11 +706,13 @@ static struct platform_device *pdev0, *pdev1;
 static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static int edma_init(void)
@@ -720,8 +726,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
-   pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
-   pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
if (EDMA_CTLRS == 2) {
@@ -731,8 +735,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
-   pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
-   pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
 out:
-- 
1.7.4.4


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

[Russell King - ARM Linux]

On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
 On Thu, 19 Sep 2013, Russell King wrote:
 
  The correct way for a driver to specify the coherent DMA mask is
  not to directly access the field in the struct device, but to use
  dma_set_coherent_mask().  Only arch and bus code should access this
  member directly.
  
  Convert all direct write accesses to using the correct API.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
  diff --git a/drivers/usb/host/ehci-platform.c 
  b/drivers/usb/host/ehci-platform.c
  index f6b790c..5b0cd2d 100644
  --- a/drivers/usb/host/ehci-platform.c
  +++ b/drivers/usb/host/ehci-platform.c
 
  @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device 
  *dev)
  dev-dev.platform_data = ehci_platform_defaults;
  if (!dev-dev.dma_mask)
  dev-dev.dma_mask = dev-dev.coherent_dma_mask;
  -   if (!dev-dev.coherent_dma_mask)
  -   dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
  +   err = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
  +   if (err)
  +   return err;
   
  pdata = dev_get_platdata(dev-dev);
 
 ehci-platform.c is a generic file, intended for use by multiple
 platforms.  Is it not possible that on some platforms, the arch or bus
 code may already have initialized the DMA masks?  Isn't something like 
 this (i.e., DMA bindings) planned for Device Tree?
 
 By eliminating the tests above and calling dma_set_coherent_mask or
 dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
 would overwrite those initial settings.
 
 I don't know to what extent the same may be true for the other,
 platform-specific, drivers changed by this patch.  But it's something 
 to be aware of.

Please check the DMA API documentation:

=
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has.  It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.

The query is performed via a call to dma_set_mask():

int dma_set_mask(struct device *dev, u64 mask);

The query for consistent allocations is performed via a call to
dma_set_coherent_mask():

int dma_set_coherent_mask(struct device *dev, u64 mask);
=

So, All drivers which use DMA are supposed to issue the appropriate
calls to check the DMA masks before they perform DMA, even if the
default is correct.

And yes, this is all part of sorting out the DT mess - we should
start not from the current mess (which is really totally haphazard)
but from the well established position of how the DMA API _should_
be used.  What that means is that all drivers should be issuing
these calls as appropriate today.

The default mask setup when the device is created is just that -
it's a default mask, and it should not be used to decide anything
about the device.  That's something which the driver should compute
on its own accord and then inform the various other layers via the
appropriate call.

Remember, on PCI, even when we have 64-bit, we do not declare PCI
devices with a 64-bit DMA mask: that's up to PCI device drivers to
_try_ to set a 64-bit DMA mask, which when successful _allows_ them
to use 64-bit DMA.  If it fails, they have to only use 32-bit.  If
they want a smaller mask, the _driver_ has to set the smaller mask,
not the device creating code.

The reason we're into this (particularly on ARM) is that we got lazy
because we could get by with declaring a DMA mask at device creation
time, since all devices were statically declared.  Now it's time to
get rid of those old lazy ways and start doing things correctly and
to the requirements of the APIs.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

[Russell King - ARM Linux]

On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
 Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
  The DMA API requires drivers to call the appropriate dma_set_mask()
  functions before doing any DMA mapping.  Add this required call to
  the AMBA PL08x driver.
   ^--- copy and paste error - should of course be PL330

Fixed, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 51/51] ARM: 7805/1: mm: change max*pfn to include the physical offset of memory

[Russell King]

From: Santosh Shilimkar santosh.shilim...@ti.com

Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.

Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/include/asm/dma-mapping.h |8 
 arch/arm/mm/init.c |   10 --
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..863cd84 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -64,6 +64,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void 
*addr)
 {
return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
 }
+
 #else
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
void *addr)
 }
 #endif
 
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+   return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev-dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8aab24f..d50533c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -426,12 +426,10 @@ void __init bootmem_init(void)
 * This doesn't seem to be used by the Linux memory manager any
 * more, but is used by ll_rw_block.  If we can get rid of it, we
 * also get rid of some of the stuff above as well.
-*
-* Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-* the system, not the maximum PFN.
 */
-   max_low_pfn = max_low - PHYS_PFN_OFFSET;
-   max_pfn = max_high - PHYS_PFN_OFFSET;
+   min_low_pfn = min;
+   max_low_pfn = max_low;
+   max_pfn = max_high;
 }
 
 /*
@@ -537,7 +535,7 @@ static inline void free_area_high(unsigned long pfn, 
unsigned long end)
 static void __init free_highpages(void)
 {
 #ifdef CONFIG_HIGHMEM
-   unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+   unsigned long max_low = max_low_pfn;
struct memblock_region *mem, *res;
 
/* set highmem page free */
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 50/51] ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King]

From: Santosh Shilimkar santosh.shilim...@ti.com

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layr
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/mmc/card/queue.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
 #include linux/freezer.h
 #include linux/kthread.h
 #include linux/scatterlist.h
+#include linux/dma-mapping.h
 
 #include linux/mmc/card.h
 #include linux/mmc/host.h
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card 
*card,
struct mmc_queue_req *mqrq_prev = mq-mqrq[1];
 
if (mmc_dev(host)-dma_mask  *mmc_dev(host)-dma_mask)
-   limit = *mmc_dev(host)-dma_mask;
+   limit = dma_max_pfn(mmc_dev(host))  PAGE_SHIFT;
 
mq-card = card;
mq-queue = blk_init_queue(mmc_request_fn, lock);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 49/51] ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King]

From: Santosh Shilimkar santosh.shilim...@ti.com

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/scsi/scsi_lib.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d1549b7..7bd7f0d 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1684,7 +1684,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
host_dev = scsi_get_device(shost);
if (host_dev  host_dev-dma_mask)
-   bounce_limit = *host_dev-dma_mask;
+   bounce_limit = dma_max_pfn(host_dev)  PAGE_SHIFT;
 
return bounce_limit;
 }
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 48/51] ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function

[Russell King]

From: Santosh Shilimkar santosh.shilim...@ti.com

Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.

To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just  dev-dma_mask  PAGE_SHIFT and hence default behavior
is maintained as is.

Subsequent patches will make use of the helper. No functional change.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 include/linux/dma-mapping.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 27d1421..fd4aee2 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -153,6 +153,13 @@ static inline int dma_set_seg_boundary(struct device *dev, 
unsigned long mask)
return -EIO;
 }
 
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+   return *dev-dma_mask  PAGE_SHIFT;
+}
+#endif
+
 static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
 {
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 47/51] ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()

[Russell King]

From: Santosh Shilimkar santosh.shilim...@ti.com

The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.

No functional change.

The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 block/blk-settings.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
 /**
  * blk_queue_bounce_limit - set bounce buffer limit for queue
  * @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
  *
  * Description:
  *Different hardware can have different requirements as to what pages
  *it can do I/O directly to. A low level driver can call
  *blk_queue_bounce_limit to have lower memory pages allocated as bounce
- *buffers for doing I/O to pages residing above @dma_mask.
+ *buffers for doing I/O to pages residing above @max_addr.
  **/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
 {
-   unsigned long b_pfn = dma_mask  PAGE_SHIFT;
+   unsigned long b_pfn = max_addr  PAGE_SHIFT;
int dma = 0;
 
q-bounce_gfp = GFP_NOIO;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 45/51] DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks

[Russell King]

This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/firmware/google/gsmi.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 6eb535f..e5a67b2 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -764,6 +764,13 @@ static __init int gsmi_system_valid(void)
 static struct kobject *gsmi_kobj;
 static struct efivars efivars;
 
+static const struct platform_device_info gsmi_dev_info = {
+   .name   = gsmi,
+   .id = -1,
+   /* SMI callbacks require 32bit addresses */
+   .dma_mask   = DMA_BIT_MASK(32),
+};
+
 static __init int gsmi_init(void)
 {
unsigned long flags;
@@ -776,7 +783,7 @@ static __init int gsmi_init(void)
gsmi_dev.smi_cmd = acpi_gbl_FADT.smi_command;
 
/* register device */
-   gsmi_dev.pdev = platform_device_register_simple(gsmi, -1, NULL, 0);
+   gsmi_dev.pdev = platform_device_register_full(gsmi_dev_info);
if (IS_ERR(gsmi_dev.pdev)) {
printk(KERN_ERR gsmi: unable to register platform device\n);
return PTR_ERR(gsmi_dev.pdev);
@@ -785,10 +792,6 @@ static __init int gsmi_init(void)
/* SMI access needs to be serialized */
spin_lock_init(gsmi_dev.lock);
 
-   /* SMI callbacks require 32bit addresses */
-   gsmi_dev.pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   gsmi_dev.pdev-dev.dma_mask =
-   gsmi_dev.pdev-dev.coherent_dma_mask;
ret = -ENOMEM;
gsmi_dev.dma_pool = dma_pool_create(gsmi, gsmi_dev.pdev-dev,
 GSMI_BUF_SIZE, GSMI_BUF_ALIGN, 0);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 46/51] ARM: DMA-API: better handing of DMA masks for coherent allocations

[Russell King]

We need to start treating DMA masks as something which is specific to
the bus that the device resides on, otherwise we're going to hit all
sorts of nasty issues with LPAE and 32-bit DMA controllers in 32-bit
systems, where memory is offset from PFN 0.

In order to start doing this, we convert the DMA mask to a PFN using
the device specific dma_to_pfn() macro.  This is the reverse of the
pfn_to_dma() macro which is used to get the DMA address for the device.

This gives us a PFN mask, which we can then check against the PFN
limit of the DMA zone.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/mm/dma-mapping.c |   49 
 arch/arm/mm/init.c|2 +
 arch/arm/mm/mm.h  |2 +
 3 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f5e1a84..13d55e1 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -173,10 +173,30 @@ static u64 get_coherent_dma_mask(struct device *dev)
return 0;
}
 
-   if ((~mask)  (u64)arm_dma_limit) {
-   dev_warn(dev, coherent DMA mask %#llx is smaller 
-than system GFP_DMA mask %#llx\n,
-mask, (u64)arm_dma_limit);
+   /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then fail the
+* allocation.
+*/
+   if (sizeof(mask) != sizeof(dma_addr_t) 
+   mask  (dma_addr_t)~0 
+   dma_to_pfn(dev, ~0)  arm_dma_pfn_limit) {
+   dev_warn(dev, Coherent DMA mask %#llx is larger than 
dma_addr_t allows\n,
+mask);
+   dev_warn(dev, Driver did not use or check the return 
value from dma_set_coherent_mask()?\n);
+   return 0;
+   }
+
+   /*
+* Now check that the mask, when translated to a PFN,
+* fits within the allowable addresses which we can
+* allocate.
+*/
+   if (dma_to_pfn(dev, mask)  arm_dma_pfn_limit) {
+   dev_warn(dev, Coherent DMA mask %#llx (pfn %#lx-%#lx) 
covers a smaller range of system memory than the DMA zone pfn 0x0-%#lx\n,
+mask,
+dma_to_pfn(dev, 0), dma_to_pfn(dev, mask) + 1,
+arm_dma_pfn_limit + 1);
return 0;
}
}
@@ -1007,8 +1027,27 @@ void arm_dma_sync_sg_for_device(struct device *dev, 
struct scatterlist *sg,
  */
 int dma_supported(struct device *dev, u64 mask)
 {
-   if (mask  (u64)arm_dma_limit)
+   unsigned long limit;
+
+   /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then we must
+* indicate that DMA to this device is not supported.
+*/
+   if (sizeof(mask) != sizeof(dma_addr_t) 
+   mask  (dma_addr_t)~0 
+   dma_to_pfn(dev, ~0)  arm_dma_pfn_limit)
+   return 0;
+
+   /*
+* Translate the device's DMA mask to a PFN limit.  This
+* PFN number includes the page which we can DMA to.
+*/
+   limit = dma_to_pfn(dev, mask);
+
+   if (limit  arm_dma_pfn_limit)
return 0;
+
return 1;
 }
 EXPORT_SYMBOL(dma_supported);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index febaee7..8aab24f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -218,6 +218,7 @@ EXPORT_SYMBOL(arm_dma_zone_size);
  * so a successful GFP_DMA allocation will always satisfy this.
  */
 phys_addr_t arm_dma_limit;
+unsigned long arm_dma_pfn_limit;
 
 static void __init arm_adjust_dma_zone(unsigned long *size, unsigned long 
*hole,
unsigned long dma_size)
@@ -240,6 +241,7 @@ void __init setup_dma_zone(const struct machine_desc *mdesc)
arm_dma_limit = PHYS_OFFSET + arm_dma_zone_size - 1;
} else
arm_dma_limit = 0x;
+   arm_dma_pfn_limit = arm_dma_limit  PAGE_SHIFT;
 #endif
 }
 
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index d5a4e9a..d5a982d 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -81,8 +81,10 @@ extern __init void add_static_vm_early(struct static_vm 
*svm);
 
 #ifdef CONFIG_ZONE_DMA
 extern phys_addr_t arm_dma_limit;
+extern unsigned long arm_dma_pfn_limit;
 #else
 #define arm_dma_limit ((phys_addr_t)~0)
+#define arm_dma_pfn_limit (~0ul  PAGE_SHIFT)
 #endif
 
 extern phys_addr_t arm_lowmem_limit;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

[Russell King]

Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks.  This can only be done when
the driver does not need to access the allocated musb platform device
from within its callbacks, which may be called during the musb
device probing.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/musb/am35x.c|   50 ++
 drivers/usb/musb/da8xx.c|   49 ++---
 drivers/usb/musb/davinci.c  |   48 ++--
 drivers/usb/musb/tusb6010.c |   49 ++---
 4 files changed, 68 insertions(+), 128 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 5c310c6..790b22b 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -89,7 +89,6 @@ struct am35x_glue {
struct clk  *phy_clk;
struct clk  *clk;
 };
-#define glue_to_musb(g)platform_get_drvdata(g-musb)
 
 /*
  * am35x_musb_enable - enable interrupts
@@ -452,14 +451,18 @@ static const struct musb_platform_ops am35x_ops = {
.set_vbus   = am35x_musb_set_vbus,
 };
 
-static u64 am35x_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info am35x_dev_info = {
+   .name   = musb-hdrc,
+   .id = PLATFORM_DEVID_AUTO,
+   .dma_mask   = DMA_BIT_MASK(32),
+};
 
 static int am35x_probe(struct platform_device *pdev)
 {
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(pdev-dev);
struct platform_device  *musb;
struct am35x_glue   *glue;
-
+   struct platform_device_info pinfo;
struct clk  *phy_clk;
struct clk  *clk;
 
@@ -471,12 +474,6 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}
 
-   musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
-   if (!musb) {
-   dev_err(pdev-dev, failed to allocate musb device\n);
-   goto err1;
-   }
-
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
@@ -503,12 +500,7 @@ static int am35x_probe(struct platform_device *pdev)
goto err6;
}
 
-   musb-dev.parent= pdev-dev;
-   musb-dev.dma_mask  = am35x_dmamask;
-   musb-dev.coherent_dma_mask = am35x_dmamask;
-
glue-dev   = pdev-dev;
-   glue-musb  = musb;
glue-phy_clk   = phy_clk;
glue-clk   = clk;
 
@@ -516,22 +508,17 @@ static int am35x_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, glue);
 
-   ret = platform_device_add_resources(musb, pdev-resource,
-   pdev-num_resources);
-   if (ret) {
-   dev_err(pdev-dev, failed to add resources\n);
-   goto err7;
-   }
-
-   ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
-   if (ret) {
-   dev_err(pdev-dev, failed to add platform_data\n);
-   goto err7;
-   }
-
-   ret = platform_device_add(musb);
-   if (ret) {
-   dev_err(pdev-dev, failed to register musb device\n);
+   pinfo = am35x_dev_info;
+   pinfo.parent = pdev-dev;
+   pinfo.res = pdev-resource;
+   pinfo.num_res = pdev-num_resources;
+   pinfo.data = pdata;
+   pinfo.size_data = sizeof(*pdata);
+
+   glue-musb = musb = platform_device_register_full(pinfo);
+   if (IS_ERR(musb)) {
+   ret = PTR_ERR(musb);
+   dev_err(pdev-dev, failed to register musb device: %d\n, 
ret);
goto err7;
}
 
@@ -550,9 +537,6 @@ static int am35x_probe(struct platform_device *pdev)
clk_put(phy_clk);
 
 err3:
-   platform_device_put(musb);
-
-err1:
kfree(glue);
 
 err0:
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d9ddf41..2f2c1cb 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -472,7 +472,11 @@ static const struct musb_platform_ops da8xx_ops = {
.set_vbus   = da8xx_musb_set_vbus,
 };
 
-static u64 da8xx_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info da8xx_dev_info = {
+   .name   = musb-hdrc,
+   .id = PLATFORM_DEVID_AUTO,
+   .dma_mask   = DMA_BIT_MASK(32),
+};
 
 static int da8xx_probe(struct platform_device *pdev)
 {
@@ -480,7 +484,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(pdev-dev);
struct platform_device  *musb;
struct da8xx_glue   *glue;
-
+   struct platform_device_info pinfo;
struct clk

[PATCH 41/51] DMA-API: crypto: remove last references to 'static struct device *dev'

[Russell King]

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/crypto/ixp4xx_crypto.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 8306185..214357e 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -221,7 +221,6 @@ static int support_aes = 1;
 #define DRIVER_NAME ixp4xx_crypto
 
 static struct platform_device *pdev;
-static struct device *dev;
 
 static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
 {
@@ -250,6 +249,7 @@ static inline const struct ix_hash_algo *ix_hash(struct 
crypto_tfm *tfm)
 
 static int setup_crypt_desc(void)
 {
+   struct device *dev = pdev-dev;
BUILD_BUG_ON(sizeof(struct crypt_ctl) != 64);
crypt_virt = dma_alloc_coherent(dev,
NPE_QLEN * sizeof(struct crypt_ctl),
@@ -350,6 +350,7 @@ static void finish_scattered_hmac(struct crypt_ctl *crypt)
 
 static void one_packet(dma_addr_t phys)
 {
+   struct device *dev = pdev-dev;
struct crypt_ctl *crypt;
struct ixp_ctx *ctx;
int failed;
@@ -419,7 +420,7 @@ static void crypto_done_action(unsigned long arg)
tasklet_schedule(crypto_done_tasklet);
 }
 
-static int init_ixp_crypto(void)
+static int init_ixp_crypto(struct device *dev)
 {
int ret = -ENODEV;
u32 msg[2] = { 0, 0 };
@@ -506,7 +507,7 @@ static int init_ixp_crypto(void)
return ret;
 }
 
-static void release_ixp_crypto(void)
+static void release_ixp_crypto(struct device *dev)
 {
qmgr_disable_irq(RECV_QID);
tasklet_kill(crypto_done_tasklet);
@@ -873,6 +874,7 @@ static int ablk_perform(struct ablkcipher_request *req, int 
encrypt)
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = ablkcipher_request_ctx(req);
struct buffer_desc src_hook;
+   struct device *dev = pdev-dev;
gfp_t flags = req-base.flags  CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
 
@@ -997,6 +999,7 @@ static int aead_perform(struct aead_request *req, int 
encrypt,
unsigned int cryptlen;
struct buffer_desc *buf, src_hook;
struct aead_ctx *req_ctx = aead_request_ctx(req);
+   struct device *dev = pdev-dev;
gfp_t flags = req-base.flags  CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
 
@@ -1426,7 +1429,7 @@ static int __init ixp_module_init(void)
spin_lock_init(desc_lock);
spin_lock_init(emerg_lock);
 
-   err = init_ixp_crypto();
+   err = init_ixp_crypto(pdev-dev);
if (err) {
platform_device_unregister(pdev);
return err;
@@ -1492,7 +1495,7 @@ static void __exit ixp_module_exit(void)
if (ixp4xx_algos[i].registered)
crypto_unregister_alg(ixp4xx_algos[i].crypto);
}
-   release_ixp_crypto();
+   release_ixp_crypto(pdev-dev);
platform_device_unregister(pdev);
 }
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

[Russell King]

The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask().  Only arch and bus code should access this
member directly.

Convert all direct write accesses to using the correct API.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/ata/pata_ixp4xx_cf.c |5 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |6 +-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(pdev-dev);
+   int ret;
 
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
 
/* acquire resources and fill host */
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
data-cs0 = devm_ioremap(pdev-dev, cs0-start, 0x1000);
data-cs1 = devm_ioremap(pdev-dev, cs1-start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
 
 static int exynos_drm_platform_probe(struct platform_device *pdev)
 {
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   int ret;
+
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
return drm_platform_init(exynos_drm_driver, pdev);
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
 
/* set dma mask for device */
-   /* NOTE: this is a workaround for the hwmod not initializing properly */
-   dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto fail;
 
omap_dmm-dummy_pa = page_to_phys(omap_dmm-dummy_page);
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 22/51] DMA-API: amba: get rid of separate dma_mask

[Russell King]

AMBA Primecell devices always treat streaming and coherent DMA exactly
the same, so there's no point in having the masks separated.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/amba/bus.c   |6 +-
 drivers/of/platform.c|3 ---
 include/linux/amba/bus.h |2 --
 3 files changed, 1 insertions(+), 10 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c670727..c4876ac 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -552,7 +552,6 @@ amba_aphb_device_add(struct device *parent, const char 
*name,
if (!dev)
return ERR_PTR(-ENOMEM);
 
-   dev-dma_mask = dma_mask;
dev-dev.coherent_dma_mask = dma_mask;
dev-irq[0] = irq1;
dev-irq[1] = irq2;
@@ -619,7 +618,7 @@ static void amba_device_initialize(struct amba_device *dev, 
const char *name)
dev_set_name(dev-dev, %s, name);
dev-dev.release = amba_device_release;
dev-dev.bus = amba_bustype;
-   dev-dev.dma_mask = dev-dma_mask;
+   dev-dev.dma_mask = dev-dev.coherent_dma_mask;
dev-res.name = dev_name(dev-dev);
 }
 
@@ -663,9 +662,6 @@ int amba_device_register(struct amba_device *dev, struct 
resource *parent)
amba_device_initialize(dev, dev-dev.init_name);
dev-dev.init_name = NULL;
 
-   if (!dev-dev.coherent_dma_mask  dev-dma_mask)
-   dev_warn(dev-dev, coherent dma mask is unset\n);
-
return amba_device_add(dev, parent);
 }
 
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..54382ba 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -284,9 +284,6 @@ static struct amba_device *of_amba_device_create(struct 
device_node *node,
else
of_device_make_bus_id(dev-dev);
 
-   /* setup amba-specific device info */
-   dev-dma_mask = ~0;
-
/* Allow the HW Peripheral ID to be overridden */
prop = of_get_property(node, arm,primecell-periphid, NULL);
if (prop)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 43ec7e2..682df0e 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -30,7 +30,6 @@ struct amba_device {
struct device   dev;
struct resource res;
struct clk  *pclk;
-   u64 dma_mask;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
 };
@@ -131,7 +130,6 @@ struct amba_device name##_device = {
\
 struct amba_device name##_device = {   \
.dev = __AMBA_DEV(busid, data, ~0ULL),  \
.res = DEFINE_RES_MEM(base, SZ_4K), \
-   .dma_mask = ~0ULL,  \
.irq = irqs,\
.periphid = id, \
 }
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

[Russell King]

The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping.  Add this required call to
the AMBA PL08x driver.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/pl330.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..df8b10f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
 
pdat = dev_get_platdata(adev-dev);
 
+   ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+
/* Allocate a new DMAC and its Channels */
pdmac = devm_kzalloc(adev-dev, sizeof(*pdmac), GFP_KERNEL);
if (!pdmac) {
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/51] DMA-API: net: emulex/benet: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/emulex/benet/be_main.c |   12 ++--
 1 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_main.c 
b/drivers/net/ethernet/emulex/benet/be_main.c
index 3224d28..2084151 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4335,19 +4335,11 @@ static int be_probe(struct pci_dev *pdev, const struct 
pci_device_id *pdev_id)
adapter-netdev = netdev;
SET_NETDEV_DEV(netdev, pdev-dev);
 
-   status = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+   status = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!status) {
-   status = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (status  0) {
-   dev_err(pdev-dev, dma_set_coherent_mask failed\n);
-   goto free_netdev;
-   }
netdev-features |= NETIF_F_HIGHDMA;
} else {
-   status = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
-   if (!status)
-   status = dma_set_coherent_mask(pdev-dev,
-  DMA_BIT_MASK(32));
+   status = dma_set_mask_and_coherent(pdev-dev, 
DMA_BIT_MASK(32));
if (status) {
dev_err(pdev-dev, Could not set PCI DMA Mask\n);
goto free_netdev;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/51] DMA-API: net: sfc/efx.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/sfc/efx.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 07c9bc4..2e27837 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1121,7 +1121,7 @@ static int efx_init_io(struct efx_nic *efx)
 */
while (dma_mask  0x7fffUL) {
if (dma_supported(pci_dev-dev, dma_mask)) {
-   rc = dma_set_mask(pci_dev-dev, dma_mask);
+   rc = dma_set_mask_and_coherent(pci_dev-dev, dma_mask);
if (rc == 0)
break;
}
@@ -1134,16 +1134,6 @@ static int efx_init_io(struct efx_nic *efx)
}
netif_dbg(efx, probe, efx-net_dev,
  using DMA mask %llx\n, (unsigned long long) dma_mask);
-   rc = dma_set_coherent_mask(pci_dev-dev, dma_mask);
-   if (rc) {
-   /* dma_set_coherent_mask() is not *allowed* to
-* fail with a mask that dma_set_mask() accepted,
-* but just in case...
-*/
-   netif_err(efx, probe, efx-net_dev,
- failed to set consistent DMA mask\n);
-   goto fail2;
-   }
 
efx-membase_phys = pci_resource_start(efx-pci_dev, EFX_MEM_BAR);
rc = pci_request_region(pci_dev, EFX_MEM_BAR, sfc);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 18/51] DMA-API: staging: et131x: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/staging/et131x/et131x.c |   17 ++---
 1 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index f73e58f..98edfa8 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -4797,21 +4797,8 @@ static int et131x_pci_setup(struct pci_dev *pdev,
pci_set_master(pdev);
 
/* Check the DMA addressing support of this device */
-   if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))) {
-   rc = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (rc  0) {
-   dev_err(pdev-dev,
- Unable to obtain 64 bit DMA for consistent 
allocations\n);
-   goto err_release_res;
-   }
-   } else if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(32))) {
-   rc = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
-   if (rc  0) {
-   dev_err(pdev-dev,
- Unable to obtain 32 bit DMA for consistent 
allocations\n);
-   goto err_release_res;
-   }
-   } else {
+   if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)) ||
+   dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32))) {
dev_err(pdev-dev, No usable DMA addressing method\n);
rc = -EIO;
goto err_release_res;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/51] DMA-API: net: intel/e1000: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/e1000/e1000_main.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..34672f8 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1018,19 +1018,14 @@ static int e1000_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 */
pci_using_dac = 0;
if ((hw-bus_type == e1000_bus_type_pcix) 
-   !dma_set_mask(pdev-dev, DMA_BIT_MASK(64))) {
-   /* according to DMA-API-HOWTO, coherent calls will always
-* succeed if the set call did
-*/
-   dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
+   !dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
pr_err(No usable DMA config, aborting\n);
goto err_dma;
}
-   dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
}
 
netdev-netdev_ops = e1000_netdev_ops;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 17/51] DMA-API: block: nvme-core: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/block/nvme-core.c |   10 --
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index da52092..26d03fa 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -1949,12 +1949,9 @@ static int nvme_dev_map(struct nvme_dev *dev)
if (pci_request_selected_regions(pdev, bars, nvme))
goto disable_pci;
 
-   if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)))
-   dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   else if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(32)))
-   dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
-   else
-   goto disable_pci;
+   if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)) 
+   dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)))
+   goto disable;
 
pci_set_drvdata(pdev, dev);
dev-bar = ioremap(pci_resource_start(pdev, 0), 8192);
@@ -2168,6 +2165,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
INIT_LIST_HEAD(dev-namespaces);
dev-pci_dev = pdev;
+
result = nvme_set_instance(dev);
if (result)
goto free;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/staging/media/dt3155v4l/dt3155v4l.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c 
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 90d6ac4..081407b 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
int err;
struct dt3155_priv *pd;
 
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
-   if (err)
-   return -ENODEV;
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err)
return -ENODEV;
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/51] DMA-API: net: broadcom/bnx2x: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2f8dbbb..e6c3e66 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12072,13 +12072,9 @@ static int bnx2x_set_coherency_mask(struct bnx2x *bp)
 {
struct device *dev = bp-pdev-dev;
 
-   if (dma_set_mask(dev, DMA_BIT_MASK(64)) == 0) {
+   if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)) == 0) {
bp-flags |= USING_DAC_FLAG;
-   if (dma_set_coherent_mask(dev, DMA_BIT_MASK(64)) != 0) {
-   dev_err(dev, dma_set_coherent_mask failed, 
aborting\n);
-   return -EIO;
-   }
-   } else if (dma_set_mask(dev, DMA_BIT_MASK(32)) != 0) {
+   } else if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) != 0) {
dev_err(dev, System does not support DMA, aborting\n);
return -EIO;
}
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 15/51] DMA-API: net: b43legacy: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/wireless/b43legacy/dma.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/b43legacy/dma.c 
b/drivers/net/wireless/b43legacy/dma.c
index 42eb26c..b2ed179 100644
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -806,12 +806,9 @@ static int b43legacy_dma_set_mask(struct b43legacy_wldev 
*dev, u64 mask)
/* Try to set the DMA mask. If it fails, try falling back to a
 * lower mask, as we can always also support a lower one. */
while (1) {
-   err = dma_set_mask(dev-dev-dma_dev, mask);
-   if (!err) {
-   err = dma_set_coherent_mask(dev-dev-dma_dev, mask);
-   if (!err)
-   break;
-   }
+   err = dma_set_mask_and_coherent(dev-dev-dma_dev, mask);
+   if (!err)
+   break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 20/51] DMA-API: usb: bcma: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/host/bcma-hcd.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c
index df13d42..205f4a3 100644
--- a/drivers/usb/host/bcma-hcd.c
+++ b/drivers/usb/host/bcma-hcd.c
@@ -227,8 +227,7 @@ static int bcma_hcd_probe(struct bcma_device *dev)
 
/* TODO: Probably need checks here; is the core connected? */
 
-   if (dma_set_mask(dev-dma_dev, DMA_BIT_MASK(32)) ||
-   dma_set_coherent_mask(dev-dma_dev, DMA_BIT_MASK(32)))
+   if (dma_set_mask_and_coherent(dev-dma_dev, DMA_BIT_MASK(32)))
return -EOPNOTSUPP;
 
usb_dev = kzalloc(sizeof(struct bcma_hcd_device), GFP_KERNEL);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 25/51] DMA-API: video: clcd: add dma_set_mask_and_coherent() call

[Russell King]

The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping.  Add this required call to
the AMBA PL08x driver.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/video/amba-clcd.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..afe4702 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -10,6 +10,7 @@
  *
  *  ARM PrimeCell PL110 Color LCD Controller
  */
+#include linux/dma-mapping.h
 #include linux/module.h
 #include linux/kernel.h
 #include linux/errno.h
@@ -551,6 +552,10 @@ static int clcdfb_probe(struct amba_device *dev, const 
struct amba_id *id)
if (!board)
return -EINVAL;
 
+   ret = dma_set_mask_and_coherent(dev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto out;
+
ret = amba_request_regions(dev, NULL);
if (ret) {
printk(KERN_ERR CLCD: unable to reserve regs region\n);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 21/51] DMA-API: usb: ssb-hcd: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/host/ssb-hcd.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ssb-hcd.c b/drivers/usb/host/ssb-hcd.c
index 74af2c6..0196f76 100644
--- a/drivers/usb/host/ssb-hcd.c
+++ b/drivers/usb/host/ssb-hcd.c
@@ -163,8 +163,7 @@ static int ssb_hcd_probe(struct ssb_device *dev,
 
/* TODO: Probably need checks here; is the core connected? */
 
-   if (dma_set_mask(dev-dma_dev, DMA_BIT_MASK(32)) ||
-   dma_set_coherent_mask(dev-dma_dev, DMA_BIT_MASK(32)))
+   if (dma_set_mask_and_coherent(dev-dma_dev, DMA_BIT_MASK(32)))
return -EOPNOTSUPP;
 
usb_dev = kzalloc(sizeof(struct ssb_hcd_device), GFP_KERNEL);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 26/51] DMA-API: usb: ohci-sa1111: add a note about DMA masks

[Russell King]

Add a comment to explain why this driver doesn't call any of the DMA
API dma_set_mask() functions.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/host/ohci-sa.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ohci-sa.c b/drivers/usb/host/ohci-sa.c
index 17b2a7d..aa9e127 100644
--- a/drivers/usb/host/ohci-sa.c
+++ b/drivers/usb/host/ohci-sa.c
@@ -185,6 +185,12 @@ static int ohci_hcd_sa_probe(struct sa_dev *dev)
if (usb_disabled())
return -ENODEV;
 
+   /*
+* We don't call dma_set_mask_and_coherent() here because the
+* DMA mask has already been appropraitely setup by the core
+* SA- bus code (which includes bug workarounds.)
+*/
+
hcd = usb_create_hcd(ohci_sa_hc_driver, dev-dev, sa);
if (!hcd)
return -ENOMEM;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 27/51] DMA-API: provide a helper to setup DMA masks

[Russell King]

Many drivers contain code such as:

dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = MASK;

Let's move this pattern out of drivers and have the DMA API provide a
helper for it.  This helper uses dma_set_mask_and_coherent() to allow
platform issues to be properly dealt with via dma_set_mask()/
dma_is_supported().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 include/linux/dma-mapping.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index ec951f9..27d1421 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -111,6 +111,16 @@ static inline int dma_set_mask_and_coherent(struct device 
*dev, u64 mask)
return rc;
 }
 
+/*
+ * Similar to the above, except it deals with the case where the device
+ * does not have dev-dma_mask appropriately setup.
+ */
+static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
+{
+   dev-dma_mask = dev-coherent_dma_mask;
+   return dma_set_mask_and_coherent(dev, mask);
+}
+
 extern u64 dma_get_required_mask(struct device *dev);
 
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers

[Russell King]

This code sequence is unsafe in modules:

static u64 mask = DMA_BIT_MASK(something);
...
if (!dev-dma_mask)
dev-dma_mask = mask;

as if a module is reloaded, the mask will be pointing at the original
module's mask address, and this can lead to oopses.  Moreover, they
all follow this with:

if (!dev-coherent_dma_mask)
dev-coherent_dma_mask = mask;

where 'mask' is the same value as the statically defined mask, and this
bypasses the architecture's check on whether the DMA mask is possible.

Fix these issues by using the new dma_coerce_coherent_and_mask()
function.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 sound/arm/pxa2xx-pcm.c  |9 +++--
 sound/soc/atmel/atmel-pcm.c |   11 ---
 sound/soc/blackfin/bf5xx-ac97-pcm.c |   11 ---
 sound/soc/blackfin/bf5xx-i2s-pcm.c  |   10 --
 sound/soc/davinci/davinci-pcm.c |9 +++--
 sound/soc/fsl/fsl_dma.c |9 +++--
 sound/soc/fsl/mpc5200_dma.c |   10 --
 sound/soc/jz4740/jz4740-pcm.c   |   12 
 sound/soc/kirkwood/kirkwood-dma.c   |9 +++--
 sound/soc/nuc900/nuc900-pcm.c   |9 -
 sound/soc/omap/omap-pcm.c   |   11 ---
 sound/soc/pxa/pxa2xx-pcm.c  |   11 ---
 sound/soc/s6000/s6000-pcm.c |9 +++--
 sound/soc/samsung/dma.c |   11 ---
 sound/soc/samsung/idma.c|   11 ---
 15 files changed, 55 insertions(+), 97 deletions(-)

diff --git a/sound/arm/pxa2xx-pcm.c b/sound/arm/pxa2xx-pcm.c
index 69a2455..fb3b76f 100644
--- a/sound/arm/pxa2xx-pcm.c
+++ b/sound/arm/pxa2xx-pcm.c
@@ -83,8 +83,6 @@ static struct snd_pcm_ops pxa2xx_pcm_ops = {
.mmap   = pxa2xx_pcm_mmap,
 };
 
-static u64 pxa2xx_pcm_dmamask = 0x;
-
 int pxa2xx_pcm_new(struct snd_card *card, struct pxa2xx_pcm_client *client,
   struct snd_pcm **rpcm)
 {
@@ -100,10 +98,9 @@ int pxa2xx_pcm_new(struct snd_card *card, struct 
pxa2xx_pcm_client *client,
pcm-private_data = client;
pcm-private_free = pxa2xx_pcm_free_dma_buffers;
 
-   if (!card-dev-dma_mask)
-   card-dev-dma_mask = pxa2xx_pcm_dmamask;
-   if (!card-dev-coherent_dma_mask)
-   card-dev-coherent_dma_mask = 0x;
+   ret = dma_coerce_mask_and_coherent_mask(card-dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto out;
 
if (play) {
int stream = SNDRV_PCM_STREAM_PLAYBACK;
diff --git a/sound/soc/atmel/atmel-pcm.c b/sound/soc/atmel/atmel-pcm.c
index 3109db7..fbb87e3 100644
--- a/sound/soc/atmel/atmel-pcm.c
+++ b/sound/soc/atmel/atmel-pcm.c
@@ -68,18 +68,15 @@ int atmel_pcm_mmap(struct snd_pcm_substream *substream,
 }
 EXPORT_SYMBOL_GPL(atmel_pcm_mmap);
 
-static u64 atmel_pcm_dmamask = DMA_BIT_MASK(32);
-
 int atmel_pcm_new(struct snd_soc_pcm_runtime *rtd)
 {
struct snd_card *card = rtd-card-snd_card;
struct snd_pcm *pcm = rtd-pcm;
-   int ret = 0;
+   int ret;
 
-   if (!card-dev-dma_mask)
-   card-dev-dma_mask = atmel_pcm_dmamask;
-   if (!card-dev-coherent_dma_mask)
-   card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_coerce_mask_and_coherent(card-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
if (pcm-streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
pr_debug(atmel-pcm: allocating PCM playback DMA buffer\n);
diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c 
b/sound/soc/blackfin/bf5xx-ac97-pcm.c
index 53f8408..1d4c676 100644
--- a/sound/soc/blackfin/bf5xx-ac97-pcm.c
+++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c
@@ -415,19 +415,16 @@ static void bf5xx_pcm_free_dma_buffers(struct snd_pcm 
*pcm)
}
 }
 
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
 static int bf5xx_pcm_ac97_new(struct snd_soc_pcm_runtime *rtd)
 {
struct snd_card *card = rtd-card-snd_card;
struct snd_pcm *pcm = rtd-pcm;
-   int ret = 0;
+   int ret;
 
pr_debug(%s enter\n, __func__);
-   if (!card-dev-dma_mask)
-   card-dev-dma_mask = bf5xx_pcm_dmamask;
-   if (!card-dev-coherent_dma_mask)
-   card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_coerce_mask_and_coherent(card-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
if (pcm-streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
ret = bf5xx_pcm_preallocate_dma_buffer(pcm,
diff --git a/sound/soc/blackfin/bf5xx-i2s-pcm.c 
b/sound/soc/blackfin/bf5xx-i2s-pcm.c
index 9cb4a80..2a5b434 100644
--- a/sound/soc/blackfin/bf5xx-i2s-pcm.c
+++ b/sound/soc/blackfin/bf5xx-i2s-pcm.c
@@ -323,18 +323,16 @@ static struct snd_pcm_ops bf5xx_pcm_i2s_ops = {
.silence= bf5xx_pcm_silence,
 };
 
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
 static int bf5xx_pcm_i2s_new(struct snd_soc_pcm_runtime *rtd

[PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()

[Russell King]

Convert this code sequence:
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
to use dma_coerce_mask_and_coherent() to avoid bypassing the architecture
check on the DMA mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/ata/pata_octeon_cf.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c
index c51bbb9..6231d43 100644
--- a/drivers/ata/pata_octeon_cf.c
+++ b/drivers/ata/pata_octeon_cf.c
@@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev)
}
cf_port-c0 = ap-ioaddr.ctl_addr;
 
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+   rv = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+   if (rv)
+   return ret;
 
ata_port_desc(ap, cmd %p ctl %p, base, ap-ioaddr.ctl_addr);
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 30/51] DMA-API: dma: dw_dmac.c: convert to use dma_coerce_mask_and_coherent()

[Russell King]

This code sequence:
if (!pdev-dev.dma_mask) {
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/dw/platform.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index e35d975..453822c 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -191,11 +191,9 @@ static int dw_probe(struct platform_device *pdev)
if (IS_ERR(chip-regs))
return PTR_ERR(chip-regs);
 
-   /* Apply default dma_mask if needed */
-   if (!dev-dma_mask) {
-   dev-dma_mask = dev-coherent_dma_mask;
-   dev-coherent_dma_mask = DMA_BIT_MASK(32);
-   }
+   err = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+   if (err)
+   return err;
 
pdata = dev_get_platdata(dev);
if (!pdata)
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()

[Russell King]

The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/media/platform/omap3isp/isp.c |6 +++---
 drivers/media/platform/omap3isp/isp.h |3 ---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index df3a0ec..1c36080 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
isp-pdata = pdata;
isp-ref_count = 0;
 
-   isp-raw_dmamask = DMA_BIT_MASK(32);
-   isp-dev-dma_mask = isp-raw_dmamask;
-   isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_coerce_mask_and_coherent(isp-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
platform_set_drvdata(pdev, isp);
 
diff --git a/drivers/media/platform/omap3isp/isp.h 
b/drivers/media/platform/omap3isp/isp.h
index cd3eff4..ce65d3a 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -152,7 +152,6 @@ struct isp_xclk {
  * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
  *  regions.
  * @mmio_size: Array with ISP register regions size in bytes.
- * @raw_dmamask: Raw DMA mask
  * @stat_lock: Spinlock for handling statistics
  * @isp_mutex: Mutex for serializing requests to ISP.
  * @crashed: Bitmask of crashed entities (indexed by entity ID)
@@ -190,8 +189,6 @@ struct isp_device {
unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
 
-   u64 raw_dmamask;
-
/* ISP Obj */
spinlock_t stat_lock;   /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/51] DMA-API: net: b43: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/wireless/b43/dma.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index c51d2dc..1d7982a 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1065,12 +1065,9 @@ static int b43_dma_set_mask(struct b43_wldev *dev, u64 
mask)
/* Try to set the DMA mask. If it fails, try falling back to a
 * lower mask, as we can always also support a lower one. */
while (1) {
-   err = dma_set_mask(dev-dev-dma_dev, mask);
-   if (!err) {
-   err = dma_set_coherent_mask(dev-dev-dma_dev, mask);
-   if (!err)
-   break;
-   }
+   err = dma_set_mask_and_coherent(dev-dev-dma_dev, mask);
+   if (!err)
+   break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 32/51] DMA-API: mmc: sdhci-acpi: use dma_coerce_mask_and_coherent()

[Russell King]

The code sequence:
dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = dma_mask;
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/mmc/host/sdhci-acpi.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index cdd4ce0..ef19874 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -310,8 +310,9 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
dma_mask = DMA_BIT_MASK(32);
}
 
-   dev-dma_mask = dev-coherent_dma_mask;
-   dev-coherent_dma_mask = dma_mask;
+   err = dma_coerce_mask_and_coherent(dev, dma_mask);
+   if (err)
+   goto err_free;
}
 
if (c-slot) {
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 33/51] DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent()

[Russell King]

The code sequence:
pldat-pdev-dev.coherent_dma_mask = 0x;
pldat-pdev-dev.dma_mask = pldat-pdev-dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/nxp/lpc_eth.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/nxp/lpc_eth.c 
b/drivers/net/ethernet/nxp/lpc_eth.c
index a061b93..ba3ca18 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1399,8 +1399,10 @@ static int lpc_eth_drv_probe(struct platform_device 
*pdev)
}
 
if (pldat-dma_buff_base_v == 0) {
-   pldat-pdev-dev.coherent_dma_mask = 0x;
-   pldat-pdev-dev.dma_mask = pldat-pdev-dev.coherent_dma_mask;
+   ret = dma_coerce_mask_and_coherent(pdev-dev, 
DMA_BIT_MASK(32));
+   if (ret)
+   goto err_out_free_irq;
+
pldat-dma_buff_size = PAGE_ALIGN(pldat-dma_buff_size);
 
/* Allocate a chunk of memory for the DMA ethernet buffers
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 34/51] DMA-API: net: octeon: use dma_coerce_mask_and_coherent()

[Russell King]

The code sequence:
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/octeon/octeon_mgmt.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c 
b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 622aa75..2006a07 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -1552,8 +1552,9 @@ static int octeon_mgmt_probe(struct platform_device *pdev)
 
p-phy_np = of_parse_phandle(pdev-dev.of_node, phy-handle, 0);
 
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
+   result = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+   if (result)
+   goto err;
 
netif_carrier_off(netdev);
result = register_netdev(netdev);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

[Russell King]

The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask().  Only arch and bus code should access this
member directly.

Convert all direct write accesses to using the correct API.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/chipidea/ci_hdrc_imx.c |5 +++--
 drivers/usb/dwc3/dwc3-exynos.c |5 +++--
 drivers/usb/gadget/lpc32xx_udc.c   |4 +++-
 drivers/usb/host/ehci-atmel.c  |5 +++--
 drivers/usb/host/ehci-octeon.c |4 +++-
 drivers/usb/host/ehci-omap.c   |8 +---
 drivers/usb/host/ehci-orion.c  |5 +++--
 drivers/usb/host/ehci-platform.c   |7 ---
 drivers/usb/host/ehci-s5p.c|5 +++--
 drivers/usb/host/ehci-spear.c  |5 +++--
 drivers/usb/host/ehci-tegra.c  |5 +++--
 drivers/usb/host/ohci-at91.c   |7 ---
 drivers/usb/host/ohci-exynos.c |5 +++--
 drivers/usb/host/ohci-nxp.c|4 +++-
 drivers/usb/host/ohci-octeon.c |4 +++-
 drivers/usb/host/ohci-omap3.c  |8 +---
 drivers/usb/host/ohci-pxa27x.c |6 --
 drivers/usb/host/ohci-spear.c  |5 +++--
 drivers/usb/host/uhci-platform.c   |5 +++--
 19 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 74d998d..bf33bd3 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -123,8 +123,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   if (!pdev-dev.coherent_dma_mask)
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto err_clk;
 
if (data-usbmisc_data) {
ret = imx_usbmisc_init(data-usbmisc_data);
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 2f2e88a..c10b324 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
 */
if (!dev-dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
-   if (!dev-coherent_dma_mask)
-   dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto err1;
 
platform_set_drvdata(pdev, exynos);
 
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index 67128be..6a2a65a 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct 
platform_device *pdev)
 udc-isp1301_i2c_client-addr);
 
pdev-dev.dma_mask = lpc32xx_usbd_dmamask;
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (retval)
+   goto resource_fail;
 
udc-board = lpc32xx_usbddata;
 
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..5831a88 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 */
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   if (!pdev-dev.coherent_dma_mask)
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (retval)
+   goto fail_create_hcd;
 
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd) {
diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c
index ab0397e..4c528b2 100644
--- a/drivers/usb/host/ehci-octeon.c
+++ b/drivers/usb/host/ehci-octeon.c
@@ -116,8 +116,10 @@ static int ehci_octeon_drv_probe(struct platform_device 
*pdev)
 * We can DMA from anywhere. But the descriptors must be in
 * the lower 4GB.
 */
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
pdev-dev.dma_mask = ehci_octeon_dma_mask;
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
hcd = usb_create_hcd(ehci_octeon_hc_driver, pdev-dev, octeon);
if (!hcd)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 78b01fa..d0759c5 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -104,7 +104,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
struct resource *res;
struct usb_hcd  *hcd;
void __iomem *regs;
-   int ret = -ENODEV;
+   int ret;
int irq;
int i

[PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()

[Russell King]

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
 drivers/usb/dwc3/dwc3-exynos.c |4 +---
 drivers/usb/host/ehci-atmel.c  |4 +---
 drivers/usb/host/ehci-omap.c   |4 +---
 drivers/usb/host/ehci-orion.c  |4 +---
 drivers/usb/host/ehci-platform.c   |5 ++---
 drivers/usb/host/ehci-s5p.c|4 +---
 drivers/usb/host/ehci-spear.c  |4 +---
 drivers/usb/host/ehci-tegra.c  |4 +---
 drivers/usb/host/ohci-at91.c   |4 +---
 drivers/usb/host/ohci-exynos.c |4 +---
 drivers/usb/host/ohci-nxp.c|3 +--
 drivers/usb/host/ohci-octeon.c |3 +--
 drivers/usb/host/ohci-omap3.c  |4 +---
 drivers/usb/host/ohci-pxa27x.c |4 +---
 drivers/usb/host/ohci-spear.c  |4 +---
 drivers/usb/host/uhci-platform.c   |4 +---
 17 files changed, 18 insertions(+), 49 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index bf33bd3..af731db 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -121,9 +121,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
pdata.phy = data-phy;
 
-   if (!pdev-dev.dma_mask)
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   ret = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (ret)
goto err_clk;
 
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index c10b324..8b20c70 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
 * Since shared usb code relies on it, set it here for now.
 * Once we move to full device tree support this will vanish off.
 */
-   if (!dev-dma_mask)
-   dev-dma_mask = dev-coherent_dma_mask;
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
goto err1;
 
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 5831a88..8e7323e 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 * Since shared usb code relies on it, set it here for now.
 * Once we have dma capability bindings this can go away.
 */
-   if (!pdev-dev.dma_mask)
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   retval = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (retval)
goto fail_create_hcd;
 
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d0759c5..6fa82d6 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 * Since shared usb code relies on it, set it here for now.
 * Once we have dma capability bindings this can go away.
 */
-   if (!dev-dma_mask)
-   dev-dma_mask = dev-coherent_dma_mask;
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
 
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 5870206..2ba7673 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -180,9 +180,7 @@ static int ehci_orion_drv_probe(struct platform_device 
*pdev)
 * set. Since shared usb code relies on it, set it here for
 * now. Once we have dma capability bindings this can go away.
 */
-   if (!pdev-dev.dma_mask)
-   pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err)
goto err1;
 
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 5b0cd2d..7f30b71 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -89,9 +89,8 @@ static int ehci_platform_probe(struct platform_device *dev)
 */
if (!dev_get_platdata(dev-dev))
dev-dev.platform_data = ehci_platform_defaults;
-   if (!dev-dev.dma_mask)
-   dev-dev.dma_mask = dev-dev.coherent_dma_mask;
-   err = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+
+   err = dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32));
if (err)
return err;
 
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 10d6a2e..d919ed4 100644

[PATCH 38/51] DMA-API: staging: use dma_set_coherent_mask()

[Russell King]

The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask().  Only arch and bus code should access this
member directly.

Convert all direct write accesses to using the correct API.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/staging/dwc2/platform.c|5 +++--
 drivers/staging/imx-drm/imx-drm-core.c |8 ++--
 drivers/staging/imx-drm/ipuv3-crtc.c   |4 +++-
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 44cce2f..1d68c49 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -100,8 +100,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
 */
if (!dev-dev.dma_mask)
dev-dev.dma_mask = dev-dev.coherent_dma_mask;
-   if (!dev-dev.coherent_dma_mask)
-   dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   retval = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+   if (retval)
+   return retval;
 
irq = platform_get_irq(dev, 0);
if (irq  0) {
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..847f430 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -805,6 +805,12 @@ static struct drm_driver imx_drm_driver = {
 
 static int imx_drm_platform_probe(struct platform_device *pdev)
 {
+   int ret;
+
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+
imx_drm_device-dev = pdev-dev;
 
return drm_platform_init(imx_drm_driver, pdev);
@@ -847,8 +853,6 @@ static int __init imx_drm_init(void)
goto err_pdev;
}
 
-   imx_drm_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32),
-
ret = platform_driver_register(imx_drm_pdrv);
if (ret)
goto err_pdrv;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 6fd37a7..9e73e8d 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -523,7 +523,9 @@ static int ipu_drm_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
 
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
 
ipu_crtc = devm_kzalloc(pdev-dev, sizeof(*ipu_crtc), GFP_KERNEL);
if (!ipu_crtc)
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/51] DMA-API: net: broadcom/b44: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/broadcom/b44.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/b44.c 
b/drivers/net/ethernet/broadcom/b44.c
index 9b017d9..b4d2018 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -2183,8 +2183,7 @@ static int b44_init_one(struct ssb_device *sdev,
goto err_out_free_dev;
}
 
-   if (dma_set_mask(sdev-dma_dev, DMA_BIT_MASK(30)) ||
-   dma_set_coherent_mask(sdev-dma_dev, DMA_BIT_MASK(30))) {
+   if (dma_set_mask_and_coherent(sdev-dma_dev, DMA_BIT_MASK(30))) {
dev_err(sdev-dev,
Required 30BIT DMA mask unsupported by the system\n);
goto err_out_powerdown;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

[Russell King - ARM Linux]

On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
 Hi,
 
 On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
  Use platform_device_register_full() for those drivers which can, to
  avoid messing directly with DMA masks.  This can only be done when
  the driver does not need to access the allocated musb platform device
  from within its callbacks, which may be called during the musb
  device probing.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
 you want me to carry this one through my tree or you prefer getting my
 Acked-by ? Either way works for me:
 
 Acked-by: Felipe Balbi ba...@ti.com
 
 there's also the third option of me setting up a branch with only this
 patch and we both merge it, that'd also work.

I think this patch is sufficiently stand-alone that it should be fine
if you want to take it through your tree.  That may be better in the
long run to avoid conflicts with this patch and any future work in
this area during this cycle.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

[Russell King - ARM Linux]

On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
 On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
  The correct way for a driver to specify the coherent DMA mask is
  not to directly access the field in the struct device, but to use
  dma_set_coherent_mask().  Only arch and bus code should access this
  member directly.
  
  Convert all direct write accesses to using the correct API.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
 Acked-by: Tejun Heo t...@kernel.org
 
 The patch is pretty widely spread.  I don't mind how it gets routed
 but what's the plan?

The plan is... I'm going to try and avoid going through the hell of
re-posting this patch series to all the recipients another time...
(It's taken some 17 hours and lots of hand holding to get this patch
set out without exim jumping off a cliff into deep OOM - soo deep that
even the OOM killer doesn't run and the CPU is 100% idle because
every single process stuck in an uninterruptible sleep waiting for
every other process to free some memory - ouch!)

I know that dealing with this patch set will be a problem due to how
widespread this is, but much of the driver level changes come down to
depending on a couple of patches.  One solution would be if I published
a branch with just the dependencies in, which subsystem maintainers
could pull, and then apply the appropriate patches on top.

Another would be if subsystem maintainers are happy that I carry them,
I can add the acks, and then later on towards the end of the cycle,
provide a branch subsystem maintainers could pull.

Or... if you can think of something easier...
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks

[Russell King - ARM Linux]

On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
 On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
 [...]
  -dma_set_coherent_mask() will always be able to set the same or a
  -smaller mask as dma_set_mask(). However for the rare case that a
  +The coherent coherent mask will always be able to set the same or a
  +smaller mask as the streaming mask. However for the rare case that a
 [...]
 
 The new wording doesn't make sense; a mask doesn't set itself.  I would
 suggest:
 
 The coherent mask can always be set to the same or a smaller mask than
 the streaming mask.

Yes, the original sentence is not particularly good, but I think even
your modified version can be interpreted as a mask setting itself
for all the same reasons that the original can be (which mask does same
refer to?)

Even so, I prefer your version.  Thanks. :)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 40/51] DMA-API: crypto: fix ixp4xx crypto platform device support

[Russell King]

Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function.  There's a reason that
warning is there and that's not for people to hide in this way.  It's
there to persuade people to use the correct APIs to allocate platform
devices.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/crypto/ixp4xx_crypto.c |   37 +
 1 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 21180d6..8306185 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -218,23 +218,10 @@ static dma_addr_t crypt_phys;
 
 static int support_aes = 1;
 
-static void dev_release(struct device *dev)
-{
-   return;
-}
-
 #define DRIVER_NAME ixp4xx_crypto
-static struct platform_device pseudo_dev = {
-   .name = DRIVER_NAME,
-   .id   = 0,
-   .num_resources = 0,
-   .dev  = {
-   .coherent_dma_mask = DMA_BIT_MASK(32),
-   .release = dev_release,
-   }
-};
 
-static struct device *dev = pseudo_dev.dev;
+static struct platform_device *pdev;
+static struct device *dev;
 
 static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
 {
@@ -1418,20 +1405,30 @@ static struct ixp_alg ixp4xx_algos[] = {
 } };
 
 #define IXP_POSTFIX -ixp4xx
+
+static const struct platform_device_info ixp_dev_info __initdata = {
+   .name   = DRIVER_NAME,
+   .id = 0,
+   .dma_mask   = DMA_BIT_MASK(32),
+};
+
 static int __init ixp_module_init(void)
 {
int num = ARRAY_SIZE(ixp4xx_algos);
-   int i,err ;
+   int i, err ;
 
-   if (platform_device_register(pseudo_dev))
-   return -ENODEV;
+   pdev = platform_device_register_full(ixp_dev_info);
+   if (IS_ERR(pdev))
+   return PTR_ERR(pdev);
+
+   dev = pdev-dev;
 
spin_lock_init(desc_lock);
spin_lock_init(emerg_lock);
 
err = init_ixp_crypto();
if (err) {
-   platform_device_unregister(pseudo_dev);
+   platform_device_unregister(pdev);
return err;
}
for (i=0; i num; i++) {
@@ -1496,7 +1493,7 @@ static void __exit ixp_module_exit(void)
crypto_unregister_alg(ixp4xx_algos[i].crypto);
}
release_ixp_crypto();
-   platform_device_unregister(pseudo_dev);
+   platform_device_unregister(pdev);
 }
 
 module_init(ixp_module_init);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call

[Russell King]

The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping.  Add this required call to
the AMBA PL08x driver.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/amba-pl08x.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index fce46c5..e51a983 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const 
struct amba_id *id)
if (ret)
return ret;
 
+   /* Ensure that we can do DMA */
+   ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto out_no_pl08x;
+
/* Create the driver state holder */
pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
if (!pl08x) {
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King]

Replace the following sequence:

dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);

with a call to the new helper dma_set_mask_and_coherent().

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/powerpc/kernel/vio.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 78a3506..96b6c97 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct 
device_node *of_node)
 
/* needed to ensure proper operation of coherent allocations
 * later, in case driver doesn't set it explicitly */
-   dma_set_mask(viodev-dev, DMA_BIT_MASK(64));
-   dma_set_coherent_mask(viodev-dev, DMA_BIT_MASK(64));
+   dma_set_mask_and_coherent(viodev-dev, DMA_BIT_MASK(64));
}
 
/* register with generic device framework */
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 35/51] DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent()

[Russell King]

The code sequence:
dev-coherent_dma_mask = DMA_BIT_MASK(24);
dev-dma_mask = dev-coherent_dma_mask;
bypasses the architectures check on the DMA mask.  It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/parport/parport_pc.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 903e128..9637615 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2004,6 +2004,7 @@ struct parport *parport_pc_probe_port(unsigned long int 
base,
struct resource *ECR_res = NULL;
struct resource *EPP_res = NULL;
struct platform_device *pdev = NULL;
+   int ret;
 
if (!dev) {
/* We need a physical device to attach to, but none was
@@ -2014,8 +2015,11 @@ struct parport *parport_pc_probe_port(unsigned long int 
base,
return NULL;
dev = pdev-dev;
 
-   dev-coherent_dma_mask = DMA_BIT_MASK(24);
-   dev-dma_mask = dev-coherent_dma_mask;
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(24));
+   if (ret) {
+   dev_err(dev, Unable to set coherent dma mask: 
disabling DMA\n);
+   dma = PARPORT_DMA_NONE;
+   }
}
 
ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/51] DMA mask changes

[Russell King - ARM Linux]

This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.

However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
rather buggy.  I tried to get some of the bug fixes in before the last
merge window, but it seems that the maintainers preferred to have the
full solution rather than a simple -rc suitable bug fix.

So, this is an attempt to clean things up.

The first point here is that drivers performing DMA should be calling
dma_set_mask()/dma_set_coherent_mask() in their probe function to verify
that DMA can be performed.  Lots of ARM drivers omit this step; please
refer to the DMA API documentation on this subject.

What this means is that the DMA mask provided by bus code is a default
value - nothing more.  It doesn't have to accurately reflect what the
device is actually capable of.  Apart from the storage for dev-dma_mask
being initialised for any device which is DMA capable, there is no other
initialisation which is strictly necessary at device creation time.

Now, these cleanups address two major areas:
1. The setting of DMA masks, particularly when both the coherent and
   streaming DMA masks are set together.

2. The initialisation of DMA masks by drivers - this seems to be becoming
   a popular habbit, one which may not be entirely the right solution.
   Rather than having this scattered throughout the tree, I've pulled
   that into a central location (and called it coercing the DMA mask -
   because it really is about forcing the DMA mask to be that value.)

3. Finally, addressing the long held misbelief that DMA masks somehow
   correspond with physical addresses.  We already have established
   long ago that dma_addr_t values returned from the DMA API are the
   values which you program into the DMA controller, and so are the
   bus addresses.  It is _only_ sane that DMA masks are also bus
   related too, and not related to physical address spaces.

(3) is a very important point for LPAE systems, which may still have
less than 4GB of memory, but this memory is all located above the 4GB
physical boundary.  This means with the current model, any device
using a 32-bit DMA mask fails - even though the DMA controller is
still only a 32-bit DMA controller but the 32-bit bus addresses map
to system memory.  To put it another way, the bus addresses have a
4GB physical offset on them.

This email is only being sent to the mailing lists in question, not to
anyone personally.  The list of individuals is far to great to do that.
I'm hoping no mailing lists reject the patches based on the number of
recipients.

Patches based on v3.12-rc1.

 Documentation/DMA-API-HOWTO.txt   |   37 +--
 Documentation/DMA-API.txt |8 +++
 arch/arm/include/asm/dma-mapping.h|8 +++
 arch/arm/mm/dma-mapping.c |   49 ++--
 arch/arm/mm/init.c|   12 +++---
 arch/arm/mm/mm.h  |2 +
 arch/powerpc/kernel/vio.c |3 +-
 block/blk-settings.c  |8 ++--
 drivers/amba/bus.c|6 +--
 drivers/ata/pata_ixp4xx_cf.c  |5 ++-
 drivers/ata/pata_octeon_cf.c  |5 +-
 drivers/block/nvme-core.c |   10 ++---
 drivers/crypto/ixp4xx_crypto.c|   48 ++--
 drivers/dma/amba-pl08x.c  |5 ++
 drivers/dma/dw/platform.c |8 +--
 drivers/dma/edma.c|6 +--
 drivers/dma/pl330.c   |4 ++
 drivers/firmware/dcdbas.c |   23 +-
 drivers/firmware/google/gsmi.c|   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |6 ++-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  |5 +-
 drivers/media/platform/omap3isp/isp.c |6 +-
 drivers/media/platform/omap3isp/isp.h |3 -
 drivers/mmc/card/queue.c  |3 +-
 drivers/mmc/host/sdhci-acpi.c |5 +-
 drivers/net/ethernet/broadcom/b44.c   |3 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c  |8 +---
 drivers/net/ethernet/brocade/bna/bnad.c   |   13 ++
 drivers/net/ethernet/emulex/benet/be_main.c   |   12 +
 drivers/net/ethernet/intel/e1000/e1000_main.c |9 +---
 drivers/net/ethernet/intel/e1000e/netdev.c|   18 +++-
 drivers/net/ethernet/intel/igb/igb_main.c |   18 +++-
 drivers/net/ethernet/intel/igbvf/netdev.c |   18 +++-
 drivers/net/ethernet/intel/ixgb/ixgb_main.c   |   16 ++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 

[PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration, 
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/igb/igb_main.c |   18 ++
 1 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
return err;
 
pci_using_dac = 0;
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (!err)
-   pci_using_dac = 1;
+   pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(pdev-dev,
-   No usable DMA configuration, 
aborting\n);
-   goto err_dma;
-   }
+   dev_err(pdev-dev,
+   No usable DMA configuration, aborting\n);
+   goto err_dma;
}
}
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks

[Russell King]

Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 Documentation/DMA-API-HOWTO.txt |   37 ++---
 Documentation/DMA-API.txt   |8 
 include/linux/dma-mapping.h |   14 ++
 3 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default 
setting,
 because this shows that you did think about these issues wrt. your
 device.
 
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
 
-   int dma_set_mask(struct device *dev, u64 mask);
+   int dma_set_mask_and_coherent(struct device *dev, u64 mask);
 
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
 
-   int dma_set_coherent_mask(struct device *dev, u64 mask);
+   The query for streaming mappings is performed via a call to
+   dma_set_mask():
+
+   int dma_set_mask(struct device *dev, u64 mask);
+
+   The query for consistent allocations is performed via a call
+   to dma_set_coherent_mask():
+
+   int dma_set_coherent_mask(struct device *dev, u64 mask);
 
 Here, dev is a pointer to the device struct of your device, and mask
 is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
 
 The standard 32-bit addressing device would do something like this:
 
-   if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+   if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
   mydev: No suitable DMA available.\n);
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent 
allocations as well,
 
int using_dac, consistent_using_dac;
 
-   if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
-   dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
-   } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+   } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
-   dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
   mydev: No suitable DMA available.\n);
goto ignore_this_device;
}
 
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
 device driver only uses consistent allocations, one would have to
 check the return value from dma_set_coherent_mask().
 
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
 
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided.  The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided.  The
+kernel will use this information later when you make DMA mappings.
 
 There is a case which we are aware of at this time, which is worth
 mentioning in this documentation.  If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API 
for use by
 driver writers.
 
 int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
 dma_set_mask(struct device *dev, u64 mask)
 
 Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static

[PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration, 
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/e1000e/netdev.c |   18 ++
 1 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
return err;
 
pci_using_dac = 0;
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (!err)
-   pci_using_dac = 1;
+   pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(pdev-dev,
-   No usable DMA configuration, 
aborting\n);
-   goto err_dma;
-   }
+   dev_err(pdev-dev,
+   No usable DMA configuration, aborting\n);
+   goto err_dma;
}
}
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA 
configuration, aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/igbvf/netdev.c |   18 ++
 1 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c 
b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
return err;
 
pci_using_dac = 0;
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (!err)
-   pci_using_dac = 1;
+   pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(pdev-dev, No usable DMA 
-   configuration, aborting\n);
-   goto err_dma;
-   }
+   dev_err(pdev-dev, No usable DMA 
+   configuration, aborting\n);
+   goto err_dma;
}
}
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}

This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/brocade/bna/bnad.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bnad.c 
b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
-   if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
-   !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
-   if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err)
-   goto release_regions;
-   }
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+   if (err)
+   goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
pr_err(No usable DMA configuration, 
aborting\n);
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/ixgb/ixgb_main.c |   16 +---
 1 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c 
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
return err;
 
pci_using_dac = 0;
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
-   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
-   if (!err)
-   pci_using_dac = 1;
+   pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   pr_err(No usable DMA configuration, 
aborting\n);
-   goto err_dma_mask;
-   }
+   pr_err(No usable DMA configuration, aborting\n);
+   goto err_dma_mask;
}
}
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration, 
aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   15 +--
 1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (err)
return err;
 
-   if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
-   !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(pdev-dev,
-   No usable DMA configuration, 
aborting\n);
-   goto err_dma;
-   }
+   dev_err(pdev-dev,
+   No usable DMA configuration, aborting\n);
+   goto err_dma;
}
pci_using_dac = 0;
}
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling

[Russell King]

The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA 
configuration, aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly.  This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   15 +--
 1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c 
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (err)
return err;
 
-   if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64)) 
-   !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
-   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(pdev-dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(pdev-dev, No usable DMA 
-   configuration, aborting\n);
-   goto err_dma;
-   }
+   dev_err(pdev-dev, No usable DMA 
+   configuration, aborting\n);
+   goto err_dma;
}
pci_using_dac = 0;
}
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 44/51] DMA-API: dcdbas: update DMA mask handing

[Russell King]

dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
which bypasses the architecture check.  Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.

Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/firmware/dcdbas.c |   23 ---
 1 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ff080ee..a85fda2 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -549,8 +549,9 @@ static int dcdbas_probe(struct platform_device *dev)
 * BIOS SMI calls require buffer addresses be in 32-bit address space.
 * This is done by setting the DMA mask below.
 */
-   dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
+   error = dma_set_coherent_mask(dcdbas_pdev-dev, DMA_BIT_MASK(32));
+   if (error)
+   return error;
 
error = sysfs_create_group(dev-dev.kobj, dcdbas_attr_group);
if (error)
@@ -581,6 +582,12 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
 };
 
+static const struct platform_device_info dcdbas_dev_info __initdata = {
+   .name   = DRIVER_NAME,
+   .id = -1,
+   .dma_mask   = DMA_BIT_MASK(32),
+};
+
 /**
  * dcdbas_init: initialize driver
  */
@@ -592,20 +599,14 @@ static int __init dcdbas_init(void)
if (error)
return error;
 
-   dcdbas_pdev = platform_device_alloc(DRIVER_NAME, -1);
-   if (!dcdbas_pdev) {
-   error = -ENOMEM;
+   dcdbas_pdev = platform_device_register_full(dcdbas_dev_info);
+   if (IS_ERR(dcdbas_pdev)) {
+   error = PTR_ERR(dcdbas_pdev);
goto err_unregister_driver;
}
 
-   error = platform_device_add(dcdbas_pdev);
-   if (error)
-   goto err_free_device;
-
return 0;
 
- err_free_device:
-   platform_device_put(dcdbas_pdev);
  err_unregister_driver:
platform_driver_unregister(dcdbas_driver);
return error;
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

[Russell King]

register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info.  So lets
make that be the case.  This avoids a direct reference to the DMA
masks by this driver.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/edma.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..7f9fe30 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
 static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static int edma_init(void)
@@ -720,8 +722,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
-   pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
-   pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
if (EDMA_CTLRS == 2) {
@@ -731,8 +731,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
-   pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
-   pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
 out:
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ufs-pltfrm: initialize DMA mask for device-tree probed device

[Russell King - ARM Linux]

On Wed, Aug 21, 2013 at 12:03:50AM +0900, Akinobu Mita wrote:
 The discussion in that thread is useful.  Also, I found that Russell King
 proposed replacing the boilerplate by using dma_coerce_mask_and_coherent()
 in his patch set Preview of DMA mask changes.
 https://patchwork.kernel.org/patch/2837359/

That is an attempt to pull all that stuff into one central place so we
don't have loads of drivers dealing with it in their own way.

As far as I can gather from those who deal with DT, such as Arnd, is that
they believe it to be wrong that the DT code sets up the DMA masks, and
they think that stuff will break if the DT code does set these pointers
up.

The big problem which we have is we have a whole bunch of drivers which
don't bother at all with the DMA set mask functions (because they've been
fiddling with the mask directly) and sorting that mess out is going to be
pretty damn difficult.

So, the above series is all about bringing stuff to a central place where
we can then start thinking about changing the behaviour and not have to
patch lots of drivers throughout the tree for every change that's made.

The way I envision the change happening is this:

1. Introduce the notion of mask coercion (drivers forcing the mask to a
   particular value.)

2. Add dma_set_mask() and similar functions to these drivers incrementally.

3. Move the initialization of the mask up to the device creation level
   (iow, the DT code) and out of the drivers (this can be done by
   adding it to the DT code, and removing it from the mask coercion code.)

4. Remove dma_coerce_mask_and_coherent() from the kernel once complete.

So, why bother with dma_coerce_mask_and_coherent()?  Not only does it
centralise the hack but it also provides a means to identify drivers
which need work and/or have been missed (you just have to grep for the
direct assignments to the DMA masks.)  Not only that but once the hack
is centralised, it removes some of the variability in the drivers, and
provides a step where we can allow things to be tested hopefully without
causing any regressions.

At least that's the theory.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/51] Preview of DMA mask changes

[Russell King - ARM Linux]

On Thu, Aug 01, 2013 at 10:34:20PM +0100, Russell King - ARM Linux wrote:
 So, this patch set is a preview of the DMA mask changes which I currently
 have in my tree.

Looking at the comments which this patch set has received, I see very
little in the way of feedback.  So I think it's time to move to the
next stage.  I will be re-posting these with a [PATCH] tag, with the
appropriate CC's, and putting them into linux-next a few days after
assuming no objections to them are forthcoming.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 00/51] Preview of DMA mask changes

[Russell King - ARM Linux]

So, this patch set is a preview of the DMA mask changes which I currently
have in my tree.

This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM.  One of those issues is how to
deal with the DT side of things, which I haven't yet addressed.

However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
rather buggy.  I tried to get some of the bug fixes in before the last
merge window, but it seems that the maintainers preferred to have the
full solution rather than a simple -rc suitable bug fix.

So, this is an attempt to clean things up.

The first point here is that drivers performing DMA should be calling
dma_set_mask()/dma_set_coherent_mask() in their probe function to verify
that DMA can be performed.  Lots of ARM drivers omit this step; please
refer to the DMA API documentation on this subject.

What this means is that the DMA mask provided by bus code is a default
value - nothing more.  It doesn't have to accurately reflect what the
device is actually capable of.  Apart from the storage for dev-dma_mask
being initialised for any device which is DMA capable, there is no other
initialisation which is strictly necessary at device creation time.

Now, these cleanups address two major areas:
1. The setting of DMA masks, particularly when both the coherent and
   streaming DMA masks are set together.

2. The initialisation of DMA masks by drivers - this seems to be becoming
   a popular habbit, one which may not be entirely the right solution.
   Rather than having this scattered throughout the tree, I've pulled
   that into a central location (and called it coercing the DMA mask -
   because it really is about forcing the DMA mask to be that value.)

3. Finally, addressing the long held misbelief that DMA masks somehow
   correspond with physical addresses.  We already have established
   long ago that dma_addr_t values returned from the DMA API are the
   values which you program into the DMA controller, and so are the
   bus addresses.  It is _only_ sane that DMA masks are also bus
   related too, and not related to physical address spaces.

(3) is a very important point for LPAE systems, which may still have
less than 4GB of memory, but this memory is all located above the 4GB
physical boundary.  This means with the current model, any device
using a 32-bit DMA mask fails - even though the DMA controller is
still only a 32-bit DMA controller but the 32-bit bus addresses map
to system memory.  To put it another way, the bus addresses have a
4GB physical offset on them.

This work is ongoing, and I'm still fixing the odd bug which the nightly
autobuilder randconfigs find (when it doesn't hit some other problem.)

I'm not using get_maintainer.pl for this series yet, because the list
of recipients is gigantic and would not pass through vger's filters,
let alone other mailing lists.  So this initial posting will only be
sent to those listed explicitly in Cc:'s in the patches, linux-kernel
and linux-arm-kernel... and it will take about an hour to send all
these patches out.

Patches based on -rc2.

 Documentation/DMA-API-HOWTO.txt   |   37 +--
 Documentation/DMA-API.txt |8 +++
 arch/arm/include/asm/dma-mapping.h|8 +++
 arch/arm/mm/dma-mapping.c |   49 ++--
 arch/arm/mm/init.c|   12 +++---
 arch/arm/mm/mm.h  |2 +
 arch/powerpc/kernel/vio.c |3 +-
 block/blk-settings.c  |8 ++--
 drivers/amba/bus.c|6 +--
 drivers/ata/pata_ixp4xx_cf.c  |5 ++-
 drivers/ata/pata_octeon_cf.c  |5 +-
 drivers/block/nvme-core.c |7 +--
 drivers/crypto/ixp4xx_crypto.c|   48 ++--
 drivers/dma/amba-pl08x.c  |5 ++
 drivers/dma/dw/platform.c |8 +--
 drivers/dma/edma.c|6 +--
 drivers/dma/pl330.c   |4 ++
 drivers/firmware/dcdbas.c |   23 +-
 drivers/firmware/google/gsmi.c|   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |7 +++-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  |5 +-
 drivers/media/platform/omap3isp/isp.c |6 +-
 drivers/media/platform/omap3isp/isp.h |3 -
 drivers/mmc/card/queue.c  |3 +-
 drivers/mmc/host/sdhci-acpi.c |5 +-
 drivers/net/ethernet/broadcom/b44.c   |3 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c  |8 +---
 drivers/net/ethernet/brocade/bna/bnad.c   |   13 ++
 

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
 On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
  On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
  The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
  on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
  PFNs but that breaks the dma_mask for few block layer drivers since
  ARM start of physical memory is not PFN0 unlike most of the architectures.
  Some more read on it is here:
 http://lwn.net/Articles/543408/
 http://lwn.net/Articles/543424/
 
  To address this issue, we introduce generic dma_max_pfn() helper which
  can be overridden from the architectures.
 
  Another intention behind move to nobootmem is also to convert ARM to
  switch to memblock and getting rid of bootmem allocator dependency which
  don't work for LPAE machines which has physical memory starting beyond
  4 GB boundary. It needs changes to core kernel and also a new memblock
  API. More on this can be found here:
 https://lkml.org/lkml/2013/6/29/77
 
  I have been trying to cook up these patches with kind help from Russell
  and we know series don't solve all the dma_mask bad assumptions. But at
  least I am hoping that it can get the ball rolling.
 
  Comments/testing help is welcome !!
  
  As this is related to some of the cleanup of dma_mask which I've been
  doing, I think it may make sense to roll this into one tree.  Any
  objection to that?
  
  Can we get any acks on this stuff from Jens and Jejb etc - especially
  for the bits which touch block/ and for the scsi bits as these are
  touching other subsystems.  (oddly, linux-scsi wasn't on the original
  mail for this series summary.)
  
 Sorry I missed the scsi lists on the summary patch.
 
 While browsing the code I found another spot in mmc layer which
 needs fixing. The patch is at the end of the email with Chris
 and linux-mmc cc'ed here.

Would you mind putting them all in the patch system, I can add the acks
should anyone supply them later, and I'll repost them along with my set
of dma-mask patches.  Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
 On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
  Would you mind putting them all in the patch system, I can add the acks
  should anyone supply them later, and I'll repost them along with my set
  of dma-mask patches.  Thanks.
  
 Done.
 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
 
 Didn't know how to get /1,2,3,4... pushed into the tracker.
 BTW, I have also pushed the patched on my git tree branch [1] just
 in case you or some one needs it.

Thanks.  I'd prefer not to have them as stable commits yet because should
we get acks from Jens, Jejb or cjb, we will need to add their acks to them.

My dma-masks branch is still very much unstable at the moment (which is
why its not published) but I shall be posting the patches during this
week.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

[Russell King - ARM Linux]

On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
 The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
 on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
 PFNs but that breaks the dma_mask for few block layer drivers since
 ARM start of physical memory is not PFN0 unlike most of the architectures.
 Some more read on it is here:
   http://lwn.net/Articles/543408/
   http://lwn.net/Articles/543424/
 
 To address this issue, we introduce generic dma_max_pfn() helper which
 can be overridden from the architectures.
   
 Another intention behind move to nobootmem is also to convert ARM to
 switch to memblock and getting rid of bootmem allocator dependency which
 don't work for LPAE machines which has physical memory starting beyond
 4 GB boundary. It needs changes to core kernel and also a new memblock
 API. More on this can be found here:
   https://lkml.org/lkml/2013/6/29/77
 
 I have been trying to cook up these patches with kind help from Russell
 and we know series don't solve all the dma_mask bad assumptions. But at
 least I am hoping that it can get the ball rolling.   
 
 Comments/testing help is welcome !!

As this is related to some of the cleanup of dma_mask which I've been
doing, I think it may make sense to roll this into one tree.  Any
objection to that?

Can we get any acks on this stuff from Jens and Jejb etc - especially
for the bits which touch block/ and for the scsi bits as these are
touching other subsystems.  (oddly, linux-scsi wasn't on the original
mail for this series summary.)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote:
 Hello.

 On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:

 DMA bounce limit is the maximum direct DMA'able memory beyond which
 bounce buffers has to be used to perform dma operations. SCSI driver
 relies on dma_mask but its calculation is based on max_*pfn which
 don't have uniform meaning across architectures. So make use of
 dma_max_pfn() which is expected to return the DMAable maximum pfn
 value across architectures.

 Cc: Russell King li...@arm.linux.org.uk
 Cc: linux-scsi@vger.kernel.org

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
   drivers/scsi/scsi_lib.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
 index 86d5220..e8275fa 100644
 --- a/drivers/scsi/scsi_lib.c
 +++ b/drivers/scsi/scsi_lib.c
 @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host 
 *shost)

  host_dev = scsi_get_device(shost);
  if (host_dev  host_dev-dma_mask)
 -bounce_limit = *host_dev-dma_mask;
 +bounce_limit = dma_max_pfn(host_dev)  PAGE_SHIFT;

You definitely forgot -1 here.

Please explain your point.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Russell King - ARM Linux]

On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote:
 diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
 index 86d5220..e8275fa 100644
 --- a/drivers/scsi/scsi_lib.c
 +++ b/drivers/scsi/scsi_lib.c
 @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
 Scsi_Host *shost)

host_dev = scsi_get_device(shost);
if (host_dev  host_dev-dma_mask)
 -bounce_limit = *host_dev-dma_mask;
 +bounce_limit = dma_max_pfn(host_dev)  PAGE_SHIFT;

 You definitely forgot -1 here.

 Please explain your point.

 Previously, 'bounce_limit' would look like 0x (unless I'm
 mistaken), now it would look like 0xf000 which is hardly what we're
 looking for, no?

Although, -1 won't give us the correct result in this case, it's more 
 like + PAGE_SIZE - 1.

And where it's used is blk_bounce_limit(), the first which that does
is convert it back to a PFN, losing the bottom bits again...

I'm tempted to suggest converting the whole thing to just deal with
PFNs rather than bytes since we only deal with can we DMA to this
on a per-page basis.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

[Russell King - ARM Linux]

On Thu, Jan 17, 2013 at 09:11:20AM +, James Bottomley wrote:
 On Wed, 2013-01-16 at 15:18 -0800, Tejun Heo wrote:
  On Wed, Jan 16, 2013 at 10:32:35AM +, James Bottomley wrote:
   diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
   index 6b2fb87..ab88c5b 100644
   --- a/arch/arm/mm/dma-mapping.c
   +++ b/arch/arm/mm/dma-mapping.c
   @@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, 
   unsigned long offset,
 op(vaddr, len, dir);
 }
 offset = 0;
   - page++;
   + page = pfn_to_page(page_to_pfn(page) + 1);
  
  Probably page = nth_page(page, 1) is the better form.
 
 It's the same thing.
 
 I'd actually prefer page = pfn_to_page(page_to_pfn(page) + 1); because
 it makes the code look like the hack it is.  The preferred form for all
 iterators like this should be to iterate over the pfn instead of a
 pointer into the page arrays, because that will always work correctly no
 matter how many weird and wonderful memory schemes we come up with.

So, why don't we update the code to do that then?
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

[Russell King - ARM Linux]

On Thu, Jan 17, 2013 at 10:37:42AM +, Russell King - ARM Linux wrote:
 On Thu, Jan 17, 2013 at 09:11:20AM +, James Bottomley wrote:
  I'd actually prefer page = pfn_to_page(page_to_pfn(page) + 1); because
  it makes the code look like the hack it is.  The preferred form for all
  iterators like this should be to iterate over the pfn instead of a
  pointer into the page arrays, because that will always work correctly no
  matter how many weird and wonderful memory schemes we come up with.
 
 So, why don't we update the code to do that then?

Also, couldn't the addition of the scatterlist offset to the page also
be buggy too?

So, what about this patch which addresses both additions by keeping our
iterator as a pfn as you suggest.  It also simplifies some of the code
in the loop too.

Can the original folk with the problem test this patch?

 arch/arm/mm/dma-mapping.c |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..076c26d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -774,25 +774,27 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
size_t size, enum dma_data_direction dir,
void (*op)(const void *, size_t, int))
 {
+   unsigned long pfn;
+   size_t left = size;
+
+   pfn = page_to_pfn(page) + offset / PAGE_SIZE;
+   offset %= PAGE_SIZE;
+
/*
 * A single sg entry may refer to multiple physically contiguous
 * pages.  But we still need to process highmem pages individually.
 * If highmem is not configured then the bulk of this loop gets
 * optimized out.
 */
-   size_t left = size;
do {
size_t len = left;
void *vaddr;
 
+   page = pfn_to_page(pfn);
+
if (PageHighMem(page)) {
-   if (len + offset  PAGE_SIZE) {
-   if (offset = PAGE_SIZE) {
-   page += offset / PAGE_SIZE;
-   offset %= PAGE_SIZE;
-   }
+   if (len + offset  PAGE_SIZE)
len = PAGE_SIZE - offset;
-   }
vaddr = kmap_high_get(page);
if (vaddr) {
vaddr += offset;
@@ -809,7 +811,7 @@ static void dma_cache_maint_page(struct page *page, 
unsigned long offset,
op(vaddr, len, dir);
}
offset = 0;
-   page++;
+   pfn++;
left -= len;
} while (left);
 }

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

[Russell King - ARM Linux]

On Thu, Jan 17, 2013 at 11:01:47AM +, James Bottomley wrote:
 On Thu, 2013-01-17 at 10:47 +, Russell King - ARM Linux wrote:
  Also, couldn't the addition of the scatterlist offset to the page also
  be buggy too?
 
 No, fortunately, offset must be within the first page from the point of
 view of block generated sg lists.  As long as nothing within arm
 violates this, it should be a safe assumption ... although the code
 seems to assume otherwise.

Are you absolutely sure about that?  I believe I have seen cases where
that has been violated in the past, though it was many years ago.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

[Russell King - ARM Linux]

On Thu, Jan 17, 2013 at 11:19:21AM +, James Bottomley wrote:
 On Thu, 2013-01-17 at 11:04 +, Russell King - ARM Linux wrote:
  On Thu, Jan 17, 2013 at 11:01:47AM +, James Bottomley wrote:
   On Thu, 2013-01-17 at 10:47 +, Russell King - ARM Linux wrote:
Also, couldn't the addition of the scatterlist offset to the page also
be buggy too?
   
   No, fortunately, offset must be within the first page from the point of
   view of block generated sg lists.  As long as nothing within arm
   violates this, it should be a safe assumption ... although the code
   seems to assume otherwise.
  
  Are you absolutely sure about that?  I believe I have seen cases where
  that has been violated in the past, though it was many years ago.
 
 From the point of view of the block layer, absolutely: the scatterlist
 is generated from an array of bio_vecs.  Each bio_vec is a page, offset
 and length element and obeys the rule that offset must be within the
 page and offset + length cannot stray over the page.

Well, I found it when working on the mmc stuff initially, long before
it got complex.  The scatterlists were unmodified from the block layer,
and I'm positive I saw occasions where the offset in the scatter lists
were larger than PAGE_SIZE.

 From the point of view of other arm stuff, I don't know.

I'm not talking about anything ARM specific here.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

[Russell King - ARM Linux]

On Wed, Jan 16, 2013 at 10:32:35AM +, James Bottomley wrote:
 On Wed, 2013-01-16 at 12:07 +0530, Subhash Jadavani wrote:
 
  Now consider this call stack from MMC block driver (this is on the ARmv7 
  based board):
   [   98.918174] [c001b50c] (v7_dma_inv_range+0x30/0x48) from 
  [c0017b8c] (dma_cache_maint_page+0x1c4/0x24c)
   [   98.927819] [c0017b8c] (dma_cache_maint_page+0x1c4/0x24c) from 
  [c0017c28] (___dma_page_cpu_to_dev+0x14/0x1c)
   [   98.937982] [c0017c28] (___dma_page_cpu_to_dev+0x14/0x1c) from 
  [c0017ff8] (dma_map_sg+0x3c/0x114)
 
 OK, so this is showing that ARM itself is making the assumption that the
 pages are contiguous in the page offset map.
 
 Fix this by doing the increment via the pfn, which will do the right
 thing whatever the memory model.
 
 Signed-off-by: James Bottomley jbottom...@parallels.com

Ok.  What would you like the patch summary line for this to be -
the existing one seems to be a little wrong given the content of
this patch...

 
 ---
 
 diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
 index 6b2fb87..ab88c5b 100644
 --- a/arch/arm/mm/dma-mapping.c
 +++ b/arch/arm/mm/dma-mapping.c
 @@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, 
 unsigned long offset,
   op(vaddr, len, dir);
   }
   offset = 0;
 - page++;
 + page = pfn_to_page(page_to_pfn(page) + 1);
   left -= len;
   } while (left);
  }
 
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 097/493] scsi: remove use of __devexit_p

[Russell King - ARM Linux]

On Mon, Nov 19, 2012 at 01:20:46PM -0500, Bill Pemberton wrote:
  drivers/scsi/arm/acornscsi.c  | 2 +-
  drivers/scsi/arm/arxescsi.c   | 2 +-
  drivers/scsi/arm/cumana_1.c   | 2 +-
  drivers/scsi/arm/cumana_2.c   | 2 +-
  drivers/scsi/arm/eesox.c  | 2 +-
  drivers/scsi/arm/oak.c| 2 +-
  drivers/scsi/arm/powertec.c   | 2 +-

For these drivers,

Acked-by: Russell King rmk+ker...@arm.linux.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 192/493] scsi: remove use of __devinit

[Russell King - ARM Linux]

On Mon, Nov 19, 2012 at 01:22:21PM -0500, Bill Pemberton wrote:
  drivers/scsi/arm/acornscsi.c  |  2 +-
  drivers/scsi/arm/arxescsi.c   |  2 +-
  drivers/scsi/arm/cumana_1.c   |  2 +-
  drivers/scsi/arm/cumana_2.c   |  2 +-
  drivers/scsi/arm/eesox.c  |  2 +-
  drivers/scsi/arm/oak.c|  2 +-
  drivers/scsi/arm/powertec.c   |  2 +-

For these,

Acked-by: Russell King rmk+ker...@arm.linux.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

[Russell King - ARM Linux]

On Sat, Sep 15, 2012 at 10:30:43AM +, Arnd Bergmann wrote:
 On Saturday 15 September 2012, Russell King - ARM Linux wrote:
  On Sat, Sep 15, 2012 at 08:00:35AM +, Arnd Bergmann wrote:
   On Friday 14 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote:
 ARM is moving to stricter checks on readl/write functions,
 so we need to use the correct types everywhere.

There's nothing wrong with const iomem pointers.  If you think
otherwise, patch x86 not to use const in its accessor implementation
and watch the reaction:

#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
{ type ret; asm volatile(mov size  %1,%0:reg (ret) \
:m (*(volatile type __force *)addr) barrier); return ret; }

build_mmio_read(readb, b, unsigned char, =q, :memory)
build_mmio_read(readw, w, unsigned short, =r, :memory)
build_mmio_read(readl, l, unsigned int, =r, :memory)
   
   Ok, fair enough. Can you fold the patch below into 
   ARM: 7500/1: io: avoid writeback addressing modes for __raw_
   accessors, or apply on top then?
  
  No - const is not appropriate for the write accessors.  Again, this puts
  us at odds with x86:
  
  #define build_mmio_write(name, size, type, reg, barrier) \
  static inline void name(type val, volatile void __iomem *addr) \
  { asm volatile(mov size  %0,%1: :reg (val), \
  m (*(volatile type __force *)addr) barrier); }
  
  build_mmio_write(writeb, b, unsigned char, q, :memory)
  build_mmio_write(writew, w, unsigned short, r, :memory)
  build_mmio_write(writel, l, unsigned int, r, :memory)
  
  So, readl etc are all const volatile void __iomem *, but writel etc are
  all volatile void __iomem *.
  
  How they're defined on ARM after 7500/1 copies how they're defined on
  x86.
 
 Well, you have to make up your mind what you want. Right now, we get these
 warnings in rpc_defconfig:
 
   Generating include/generated/mach-types.h
 /home/arnd/linux-arm/drivers/net/ethernet/seeq/ether3.c: In function 
 'ether3_outb':
 /home/arnd/linux-arm/drivers/net/ethernet/seeq/ether3.c:104:2: error: passing 
 argument 2 of '__raw_writeb' discards 'const' qualifier from pointer target 
 type [-Werror]
 /home/arnd/linux-arm/arch/arm/include/asm/io.h:81:91: note: expected 
 'volatile void *' but argument is of type 'const void *'
 /home/arnd/linux-arm/drivers/scsi/arm/eesox.c: In function 
 'eesoxscsi_buffer_out':
 /home/arnd/linux-arm/drivers/scsi/arm/eesox.c:310:4: error: passing argument 
 2 of '__raw_writel' discards 'const' qualifier from pointer target type 
 [-Werror]
 /home/arnd/linux-arm/arch/arm/include/asm/io.h:88:91: note: expected 
 'volatile void *' but argument is of type 'const void *'
 /home/arnd/linux-arm/drivers/scsi/arm/eesox.c:324:4: error: passing argument 
 2 of '__raw_writel' discards 'const' qualifier from pointer target type 
 [-Werror]
 /home/arnd/linux-arm/arch/arm/include/asm/io.h:88:91: note: expected 
 'volatile void *' but argument is of type 'const void *'
 /home/arnd/linux-arm/drivers/scsi/arm/eesox.c:325:4: error: passing argument 
 2 of '__raw_writel' discards 'const' qualifier from pointer target type 
 [-Werror]
 /home/arnd/linux-arm/arch/arm/include/asm/io.h:88:91: note: expected 
 'volatile void *' but argument is of type 'const void *'
 
 Either we allow drivers to write to const __iomem pointers or we don't. I
 don't care which way we do it, but just saying both patches are wrong is
 not very helpful.

In both of my replies, I've said as x86 does.  We need to follow
x86's behaviour here, which is as I've quoted - it's not a matter
that I need to make up my mind - my mind is already well made up.
That is, we need to follow x86 here.

That is, const volatile void __iomem * for reads, and volatile void
__iomem * for writes.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

[Russell King - ARM Linux]

On Sat, Sep 15, 2012 at 08:00:35AM +, Arnd Bergmann wrote:
 On Friday 14 September 2012, Russell King - ARM Linux wrote:
  On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote:
   ARM is moving to stricter checks on readl/write functions,
   so we need to use the correct types everywhere.
  
  There's nothing wrong with const iomem pointers.  If you think
  otherwise, patch x86 not to use const in its accessor implementation
  and watch the reaction:
  
  #define build_mmio_read(name, size, type, reg, barrier) \
  static inline type name(const volatile void __iomem *addr) \
  { type ret; asm volatile(mov size  %1,%0:reg (ret) \
  :m (*(volatile type __force *)addr) barrier); return ret; }
  
  build_mmio_read(readb, b, unsigned char, =q, :memory)
  build_mmio_read(readw, w, unsigned short, =r, :memory)
  build_mmio_read(readl, l, unsigned int, =r, :memory)
 
 Ok, fair enough. Can you fold the patch below into 
 ARM: 7500/1: io: avoid writeback addressing modes for __raw_
 accessors, or apply on top then?

No - const is not appropriate for the write accessors.  Again, this puts
us at odds with x86:

#define build_mmio_write(name, size, type, reg, barrier) \
static inline void name(type val, volatile void __iomem *addr) \
{ asm volatile(mov size  %0,%1: :reg (val), \
m (*(volatile type __force *)addr) barrier); }

build_mmio_write(writeb, b, unsigned char, q, :memory)
build_mmio_write(writew, w, unsigned short, r, :memory)
build_mmio_write(writel, l, unsigned int, r, :memory)

So, readl etc are all const volatile void __iomem *, but writel etc are
all volatile void __iomem *.

How they're defined on ARM after 7500/1 copies how they're defined on
x86.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

[Russell King - ARM Linux]

On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote:
 ARM is moving to stricter checks on readl/write functions,
 so we need to use the correct types everywhere.

There's nothing wrong with const iomem pointers.  If you think
otherwise, patch x86 not to use const in its accessor implementation
and watch the reaction:

#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
{ type ret; asm volatile(mov size  %1,%0:reg (ret) \
:m (*(volatile type __force *)addr) barrier); return ret; }

build_mmio_read(readb, b, unsigned char, =q, :memory)
build_mmio_read(readw, w, unsigned short, =r, :memory)
build_mmio_read(readl, l, unsigned int, =r, :memory)

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html