Remove the "not" before "cannot".

I am fixing the comment block style while I am here.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NRob Herring <robh@kernel.org>

If non-LPAE kernel is booted up on a machine with 64-bit PCI resources,
PCI controller probe fails with:

PCI host bridge /pcie@10000000 ranges:
   IO 0x3eff0000..0x3effffff -> 0x00000000
  MEM 0x10000000..0x3efeffff -> 0x10000000
  MEM 0x8000000000..0xffffffffff -> 0x8000000000
pci-host-generic 3f000000.pcie: resource collision: [mem 0x00000000-0xffffffff] conflicts with /pl011@9000000 [mem 0x09000000-0x09000fff]
pci-host-generic: probe of 3f000000.pcie failed with error -16

This happens because res->start assignment in of_pci_range_to_resource()
truncates the upper part of the address, because res->start is of
phys_addr_t type, which is 32-bit on non-LPAE kernels.

This patch adds explicit recognition of 64-bit resources, preventing from
potential problems when e. g. 0x8000001234 would be converted to
0x00001234.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NRob Herring <robh@kernel.org>

If the internal call to of_address_to_resource() fails, we end up
looping forever in of_find_matching_node_by_address().  This can be
caused by a defective device tree, or calling with an incorrect
matches argument.

Fix by calling of_find_matching_node() unconditionally at the end of
the loop.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>

When kzalloc() is called under spin_lock(), GFP_ATOMIC should be
used to avoid sleeping allocation.
The call tree is:
  of_pci_range_to_resource()
    --> pci_register_io_range() <-- takes spin_lock(&io_range_lock);
       --> kzalloc()
Signed-off-by: NJingoo Han <jingoohan1@gmail.com>
Cc: stable@vger.kernel.org # 3.18+
Signed-off-by: NRob Herring <robh@kernel.org>

41f8bba7 ("of/pci: Add pci_register_io_range() and
pci_pio_to_address()") added support for systems with several I/O ranges
described by OF bindings.  It modified pci_address_to_pio() look up the
io_range for a given CPU physical address, but the conversion was wrong.

Fix the conversion of address to I/O port.

[bhelgaas: changelog]
Fixes: 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()")
Signed-off-by: NZhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
CC: stable@vger.kernel.org	# v3.18+

The "sdc" node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.

Fixes 746c9e9f, "of/base: Fix PowerPC address parsing hack"
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Stable <stable@vger.kernel.org> # v3.18+

The "sdc" node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.

Fixes 746c9e9f, "of/base: Fix PowerPC address parsing hack"
Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Stable <stable@vger.kernel.org> # v3.18+

We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac "bad"
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.

This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>

The core always tries to translate any "reg" property to construct the platform
device names. This results in a pile of "OF: no ranges; cannot translate" errors
in dmesg whenever we expose things like i2c devices that cannot directly translate
to the MMIO space.

Turn this into a pr_debug instead
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

This patch makes the name argument from of_io_request_and_map constant.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

The ranges property for a host bridge controller in DT describes the
mapping between the PCI bus address and the CPU physical address.  The
resources framework however expects that the IO resources start at a pseudo
"port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.  The
conversion from PCI ranges to resources failed to take that into account,
returning a CPU physical address instead of a port number.

Also fix all the drivers that depend on the old behaviour by fetching the
CPU physical address based on the port number where it is being needed.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Thierry Reding <thierry.reding@gmail.com>
CC: Simon Horman <horms@verge.net.au>
CC: Catalin Marinas <catalin.marinas@arm.com>

We need to enhance of_pci_range_to_resources() enough that it won't make
sense for it to be inline anymore.  Move it to drivers/of/address.c, under
#ifdef CONFIG_PCI.

of_address.h previously implemented of_pci_range_to_resources()
unconditionally, regardless of any config options.  The implementation in
address.c is defined only when CONFIG_OF_ADDRESS=y and CONFIG_PCI=y,
so add a dummy version to avoid build errors when CONFIG_OF or
CONFIG_OF_ADDRESS is not defined.

[bhelgaas: drop extra detail from changelog, move def under CONFIG_PCI,
add dummy of_pci_range_to_resource() for build errors (from Arnd)]
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>

Some architectures do not have a simple view of the PCI I/O space and
instead use a range of CPU addresses that map to bus addresses.  For some
architectures these ranges will be expressed by OF bindings in a device
tree file.

This patch introduces a pci_register_io_range() helper function with a
generic implementation that can be used by such architectures to keep track
of the I/O ranges described by the PCI bindings.  If the PCI_IOBASE macro
is not defined, that signals lack of support for PCI and we return an
error.

In order to retrieve the CPU address associated with an I/O port, a new
helper function pci_pio_to_address() is introduced.  This will search in
the list of ranges registered with pci_register_io_range() and return the
CPU address that corresponds to the given port.

[arnd: add dummy !CONFIG_OF pci_pio_to_address() to fix build errors]
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NRob Herring <robh@kernel.org>
CC: Grant Likely <grant.likely@linaro.org>

A call to of_iomap does not request the memory region. This patch adds the
function of_io_request_and_map which requests the memory region before
mapping it.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Suggested-by: NRob Herring <robh@kernel.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>

of_can_translate_address only checks some conditions for address
translation, but does not check other conditions like having range
properties. The checks it does do are redundant with
__of_address_translate. The only difference is printing a message or
not. Since we only have a single caller that does the full translation
anyway, just remove of_can_translate_address and quiet the error
message.

Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Tested-by: NFrank Rowand <frank.rowand@sonymobile.com>
Reviewed-by: NFrank Rowand <frank.rowand@sonymobile.com>

The of_dma_is_coherent() helper parses the given DT device
node to see if the "dma-coherent" property is supported and
returns true or false accordingly.

If the arch is always coherent or always noncoherent, then the default
DMA ops has to be specified accordingly.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>

The of_dma_get_range() allows to find "dma-range" property for
the specified device and parse it.
 dma-ranges format:
   DMA addr (dma_addr)          : naddr cells
   CPU addr (phys_addr_t)       : pna cells
   size                         : nsize cells

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Translating an address from a PCI node of the device-tree into a CPU
physical address doesn't require the core PCI support. Those
translations are just related to the device tree itself.

The use case to translate an address from a PCI node without actually
using the PCI core support is when one needs to access the PCI
controller without accessing any PCI devices.

Marvell SoCs, such as Kirkwood, Dove or Armada XP for instance, come
with an IP of a PCI controller. In the registers of this controller
are stored the ID and the revision of a SoC. With this patch it will
be possible to read the SoC ID of a board without any PCI device and
then without the PCI core support.
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

On IBM pseries systems the device_type device-tree property of a PCIe
bridge contains the string "pciex". The of_bus_pci_match() function was
looking only for "pci" on this property, so in such cases the bus
matching code was falling back to the default bus, causing problems on
functions that should be using "assigned-addresses" for region address
translation. This patch fixes the problem by also looking for "pciex" on
the PCI bus match function.

v2: added comment
Signed-off-by: NKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>

This reverts commit e38c0a1f.

Nikita Yushchenko reports:
While trying to make freescale p2020ds and  mpc8572ds boards working
with mainline kernel, I faced that commit e38c0a1f (Handle

Both these boards have uli1575 chip.
Corresponding part in device tree is something like

                uli1575@0 {
                        reg = <0x0 0x0 0x0 0x0 0x0>;
                        #size-cells = <2>;
                        #address-cells = <3>;
                        ranges = <0x2000000 0x0 0x80000000
                                  0x2000000 0x0 0x80000000
                                  0x0 0x20000000

                                  0x1000000 0x0 0x0
                                  0x1000000 0x0 0x0
                                  0x0 0x10000>;
                        isa@1e {
...

I.e. it has #address-cells = <3>

With commit e38c0a1f reverted, devices under uli1575 are registered
correctly, e.g. for rtc

OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address: 00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=a0000000, s=20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 01000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 01000000 00000000 00000070
OF: parent bus is default (na=2, ns=2) on /
OF: walking ranges...
OF: PCI map, cp=0, s=10000, da=70
OF: parent translation for: 00000000 ffc10000
OF: with offset: 70
OF: one level translation: 00000000 ffc10070
OF: reached root node

With commit e38c0a1f in place, address translation fails:

OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
OF: translating address: 00000001 00000070
OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
OF: walking ranges...
OF: ISA map, cp=0, s=1000, da=70
OF: parent translation for: 01000000 00000000 00000000
OF: with offset: 70
OF: one level translation: 00000000 00000000 00000070
OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
OF: walking ranges...
OF: default map, cp=a0000000, s=20000000, da=70
OF: default map, cp=0, s=10000, da=70
OF: not found !

Thierry Reding confirmed this commit was not needed after all:
"We ended up merging a different address representation for Tegra PCIe
and I've confirmed that reverting this commit doesn't cause any obvious
regressions. I think all other drivers in drivers/pci/host ended up
copying what we did on Tegra, so I wouldn't expect any other breakage
either."

There doesn't appear to be a simple way to support both behaviours, so
reverting this as nothing should be depending on the new behaviour.

Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: NRob Herring <robh@kernel.org>

The OF irq handling code has been overloading the term 'map' to refer to
both parsing the data in the device tree and mapping it to the internal
linux irq system. This is probably because the device tree does have the
concept of an 'interrupt-map' function for translating interrupt
references from one node to another, but 'map' is still confusing when
the primary purpose of some of the functions are to parse the DT data.

This patch renames all the of_irq_map_* functions to of_irq_parse_*
which makes it clear that there is a difference between the parsing
phase and the mapping phase. Kernel code can make use of just the
parsing or just the mapping support as needed by the subsystem.

The patch was generated mechanically with a handful of sed commands.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Acked-by: NMichal Simek <monstr@monstr.eu>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Several locations in the of_address and of_irq code dereference the
full_name parameter from a device_node pointer without checking if the
pointer is valid.  This patch switches to use of_node_full_name() which
always checks the pointer.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

Implement pci_address_to_pio as weak function to remove the dependency on
asm/prom.h. This is in preparation to make prom.h optional.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Grant Likely <grant.likely@linaro.org>

 Commit:

  e38c0a1f
  of/address: Handle #address-cells > 2 specially

broke real time clock access on Bimini, js2x, and similar powerpc
machines using the "maple" platform. That code was indirectly relying
on the old (broken) behaviour of the translation for the hypertransport
to ISA bridge.

This fixes it by treating hypertransport as a PCI bus
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

	struct of_pci_range_parser parser;
	struct of_pci_range range;

	if (of_pci_range_parser_init(&parser, np))
		; //no ranges property

	for_each_of_pci_range(&parser, &range) {

		/*
			directly access properties of the address range, e.g.:
			range.pci_space, range.pci_addr, range.cpu_addr,
			range.size, range.flags

			alternatively obtain a struct resource, e.g.:
			struct resource res;
			of_pci_range_to_resource(&range, np, &res);
		*/
	}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: NAndrew Murray <Andrew.Murray@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRob Herring <rob.herring@calxeda.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Signed-off-by: NAndrew Murray <Andrew.Murray@arm.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

drivers/of/address.c:66:29: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:66:29:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:66:29:    got unsigned int [usertype] *addr
drivers/of/address.c:87:32: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:87:32:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:87:32:    got unsigned int [usertype] *addr
drivers/of/address.c:91:30: warning: incorrect type in assignment (different base types)
drivers/of/address.c:91:30:    expected unsigned int [unsigned] [usertype] <noident>
drivers/of/address.c:91:30:    got restricted __be32 [usertype] <noident>
drivers/of/address.c:92:22: warning: incorrect type in assignment (different base types)
drivers/of/address.c:92:22:    expected unsigned int [unsigned] [usertype] <noident>
drivers/of/address.c:92:22:    got restricted __be32 [usertype] <noident>
drivers/of/address.c:147:35: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:147:35:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:147:35:    got unsigned int [usertype] *addr
drivers/of/address.c:157:34: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:157:34:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:157:34:    got unsigned int [usertype] *
drivers/of/address.c:256:29: warning: restricted __be32 degrades to integer
drivers/of/address.c:256:36: warning: restricted __be32 degrades to integer
drivers/of/address.c:262:34: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:262:34:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:262:34:    got unsigned int [usertype] *
drivers/of/address.c:372:41: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:372:41:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:372:41:    got unsigned int [usertype] *addr
drivers/of/address.c:395:53: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:395:53:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:395:53:    got unsigned int [usertype] *addr
drivers/of/address.c:443:50: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:443:50:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:443:50:    got unsigned int *<noident>
drivers/of/address.c:455:49: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:455:49:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:455:49:    got unsigned int *<noident>
drivers/of/address.c:480:60: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:480:60:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:480:60:    got unsigned int *<noident>
drivers/of/address.c:412:5: warning: symbol '__of_translate_address' was not declared. Should it be static?
drivers/of/address.c:520:14: error: symbol 'of_get_address' redeclared with different type (originally declared at include/linux/of_address.h:22) - different base types
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

When a bus specifies #address-cells > 2, of_bus_default_map() now
assumes that the mapping isn't for a physical address but rather an
identifier that needs to match exactly.

This is required by bindings that use multiple cells to translate a
resource to the parent bus (device index, type, ...).

See here for the discussion:

	https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-June/016577.htmlOriginally-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

It's quite legitimate for a DT node to specify #size-cells=0. One example
is a node that's used to collect a number of non-memory-mapped devices.
In that scenario, there may be multiple child nodes with the same name
(type) thus necessitating the use of unit addresses in node names, and
reg properties:

/ {
	regulators {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <0>;

		regulator@0 {
			compatible = "regulator-fixed";
			reg = <0>;
			...
		};

		regulator@1 {
			compatible = "regulator-fixed";
			reg = <1>;
			...
		};

		...
	};
};

However, #size-cells=0 prevents translation of reg property values into
the parent node's address space. In turn, this triggers the kernel to
emit error messages during boot, such as:

    prom_parse: Bad cell count for /regulators/regulator@0

To prevent printing these error messages for legitimate DT content, a
number of changes are made:

1) of_get_address()/of_get_pci_address() are modified only to validate
   the value of #address-cells, and not #size-cells.

2) of_can_translate_address() is added to indicate whether address
   translation is possible.

3) of_device_make_bus_id() is modified to name devices based on the
   translated address only where possible, and otherwise fall back to
   using the (first cell of the) raw untranslated address.

4) of_device_alloc() is modified to create memory resources for a device
   only if the address can be translated into the CPU's address space.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

The register and irq definitions in mach/*.h for spear3xx and
spear6xx are now mostly obsolete, after the platforms have been
converted to device tree based probing and the data is now
part of the device tree files.

The misc_regs.h contents are moved into clock.c because that is
the only user, aside from the DMA_CHN_CFG that should eventually
get handled differently. Some of the contents of mach/spear.h
still remain, because they are used to set up the static map table,
timer, uart and auxdata tables, but almost everything got removed.
We might remove everything but the map table as the DT conversion
completes, but that is not a priority. I've also made sure to
make both copies of spear.h more or less identical so we can
eventually combine them.

The spear3?0.h files were only used by the spear3?0.c files, so I
merged the contents in there and removed the bits that were unused.
This is something that should still be looked at.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NViresh Kumar <viresh.kumar@st.com>

Add a reg-names property to allow for reg regions to be reference by name
instead of by index.  Some devices have multiple register regions which
are more naturally referenced by name.

If the name is available, use it to name the resource when creating a devices.
Otherwise keep the device name.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
[Generalized documentation to be for any -names property]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

that should be the approved way of calculating
the size of resources. No functional changes.

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

of_find_matching_node_by_address() can be used to find a device tree
node for a device at a specific address.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This patch changes u32 to __be32 for all "ranges", "prop" and "addr" and
such. Those variables are pointing to the device tree which contains
integers in big endian format.

Most functions are doing it right because of_read_number() is doing the
right thing for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
of_bus_isa_map() were accessing the data directly and were doing it wrong.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This patch changes u32 to __be32 for all "ranges", "prop" and "addr" and
such. Those variables are pointing to the device tree which containts
intergers in big endian format.
Most functions are doing it right because of_read_number() is doing the
right thing for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
of_bus_isa_map() were accessing the data directly and were doing it wrong.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Use the sparse annotations so we can keep track of endianness.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Resource names appear in human readable output, so when extracting IRQ
and address resources from a device tree node, use the full node name
to give proper context in places like /proc/iomem.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
CC: Michal Simek <monstr@monstr.eu>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: microblaze-uclinux@itee.uq.edu.au
CC: linuxppc-dev@ozlabs.org

Certain Apple machines don't use the ranges property correctly, but the
workaround should not be applied on other architectures.  This patch
disables the workaround for non-powerpc architectures.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Stephen Rothwell <sfr@canb.auug.org.au>

Fix some endian issues in the OF address translation code.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Michal Simek <monstr@monstr.eu>
CC: Stephen Rothwell <sfr@canb.auug.org.au>

Microblaze and PowerPC share a large chunk of code for translating
OF device tree data into usable addresses.  Differences between the two
consist of cosmetic differences, and the addition of dma-ranges support
code to powerpc but not microblaze.  This patch moves the powerpc
version into common code and applies many of the cosmetic (non-functional)
changes from the microblaze version.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Michal Simek <monstr@monstr.eu>
CC: Wolfram Sang <w.sang@pengutronix.de>
CC: Stephen Rothwell <sfr@canb.auug.org.au>