1. 30 9月, 2014 1 次提交
    • L
      of/pci: Add pci_register_io_range() and pci_pio_to_address() · 41f8bba7
      Liviu Dudau 提交于
      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>
      41f8bba7
  2. 23 7月, 2014 1 次提交
  3. 14 5月, 2014 1 次提交
  4. 06 5月, 2014 2 次提交
  5. 10 10月, 2013 3 次提交
  6. 20 5月, 2013 1 次提交
  7. 24 11月, 2012 1 次提交
  8. 10 11月, 2012 1 次提交
    • A
      of/address: sparc: Declare of_address_to_resource() as an extern function for sparc again · 0bce04be
      Andreas Larsson 提交于
      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 a850a755, "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 <sam@ravnborg.org>
      Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
      Acked-by: NRob Herring <rob.herring@calxeda.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bce04be
  9. 18 10月, 2012 1 次提交
    • K
      of/address: sparse fixes · 47b1e689
      Kim Phillips 提交于
      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>
      47b1e689
  10. 03 8月, 2012 1 次提交
    • S
      of: Allow busses with #size-cells=0 · 5d61b165
      Stephen Warren 提交于
      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>
      5d61b165
  11. 16 2月, 2012 1 次提交
  12. 19 7月, 2011 2 次提交
  13. 24 12月, 2010 1 次提交
  14. 09 12月, 2010 1 次提交
  15. 01 8月, 2010 1 次提交
    • G
      of/address: Clean up function declarations · 22ae782f
      Grant Likely 提交于
      This patch moves the declaration of of_get_address(), of_get_pci_address(),
      and of_pci_address_to_resource() out of arch code and into the common
      linux/of_address header file.
      
      This patch also fixes some of the asm/prom.h ordering issues.  It still
      includes some header files that it ideally shouldn't be, but at least the
      ordering is consistent now so that of_* overrides work.
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      22ae782f
  16. 06 7月, 2010 3 次提交