user/sven/linux.git/include/linux/of_address.h, branch v3.14.79

of: move of_translate_dma_address to of_address.h

2013-10-10T01:04:10Z

of_translate_dma_address is implemented in common code, so move the declaration there too. Signed-off-by: Rob Herring Acked-by: Grant Likely Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org

of: move of_address_to_resource and of_iomap declarations from sparc

2013-10-10T01:04:09Z

Move of_address_to_resource and of_iomap declarations to common code. These only differ on sparc, but the declarations are the same and don't need to be in arch header. Signed-off-by: Rob Herring Acked-by: Grant Likely Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org

of: implement pci_address_to_pio as weak function

2013-10-10T01:04:06Z

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: Rob Herring Acked-by: Grant Likely Cc: Michal Simek Cc: Ralf Baechle Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: Grant Likely

of/pci: Provide support for parsing PCI DT ranges property

2013-05-19T20:29:55Z

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: Andrew Murray Signed-off-by: Liviu Dudau Signed-off-by: Thomas Petazzoni Reviewed-by: Rob Herring Tested-by: Thomas Petazzoni Tested-by: Linus Walleij Tested-by: Jingoo Han Acked-by: Grant Likely Signed-off-by: Jason Cooper

of/address: sparc: Declare of_iomap as an extern function for sparc again

2012-11-23T22:01:15Z

This bug-fix makes sure that of_iomap is defined extern for sparc so that the sparc-specific implementation of_iomap is once again used when including include/linux/of_address.h in a sparc context. OF_GPIO that is now available for sparc relies on this. The bug was inadvertently introduced in a850a75, "of/address: add empty static inlines for !CONFIG_OF", that added a static dummy inline for of_iomap when !CONFIG_OF_ADDRESS. However, CONFIG_OF_ADDRESS is never defined for sparc, but there is a sparc-specific implementation /arch/sparc/kernel/of_device_common.c. This fix takes the same approach as 0bce04b that solved the equivalent problem for of_address_to_resource. Signed-off-by: Andreas Larsson Acked-by: David Miller Signed-off-by: Grant Likely

of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again

2012-11-10T00:30:50Z

This bug-fix makes sure that of_address_to_resource is defined extern for sparc so that the sparc-specific implementation of of_address_to_resource() is once again used when including include/linux/of_address.h in a sparc context. A number of drivers in mainline relies on this function working for sparc. The bug was introduced in a850a7554442f08d3e910c6eeb4ee216868dda1e, "of/address: add empty static inlines for !CONFIG_OF". Contrary to that commit title, the static inlines are added for !CONFIG_OF_ADDRESS, and CONFIG_OF_ADDRESS is never defined for sparc. This is good behavior for the other functions in include/linux/of_address.h, as the extern functions defined in drivers/of/address.c only gets linked when OF_ADDRESS is configured. However, for of_address_to_resource there exists a sparc-specific implementation in arch/sparc/arch/sparc/kernel/of_device_common.c Solution suggested by: Sam Ravnborg Signed-off-by: Andreas Larsson Acked-by: Rob Herring Signed-off-by: David S. Miller

of/address: sparse fixes

2012-10-17T20:53:01Z

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] drivers/of/address.c:91:30: got restricted __be32 [usertype] 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] drivers/of/address.c:92:22: got restricted __be32 [usertype] 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 * 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 * 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 * 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: Kim Phillips Signed-off-by: Rob Herring

of: Allow busses with #size-cells=0

2012-08-03T13:01:46Z

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: Stephen Warren Signed-off-by: Rob Herring

of/address: add empty static inlines for !CONFIG_OF

2012-02-16T13:11:23Z

As the title says, this patch adds empty implementations for the address translation functions so that they can be used when CONFIG_OF is disabled. Signed-off-by: Grant Likely Cc: Rob Herring

dt: include linux/errno.h in linux/of_address.h

2011-07-18T22:37:45Z

of_address.h makes reference to some of the error code #defines, so it needs to include errno.h. If CONFIG_PCI is not selected, then some files will fail to compile. Signed-off-by: Grant Likely