1. 06 Dec, 2014 1 commit
  2. 14 Nov, 2014 1 commit
    • Grant Likely's avatar
      of: Fix overflow bug in string property parsing functions · 96db9738
      Grant Likely authored
      commit a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream.
      The string property read helpers will run off the end of the buffer if
      it is handed a malformed string property. Rework the parsers to make
      sure that doesn't happen. At the same time add new test cases to make
      sure the functions behave themselves.
      The original implementations of of_property_read_string_index() and
      of_property_count_strings() both open-coded the same block of parsing
      code, each with it's own subtly different bugs. The fix here merges
      functions into a single helper and makes the original functions static
      inline wrappers around the helper.
      One non-bugfix aspect of this patch is the addition of a new wrapper,
      of_property_read_string_array(). The new wrapper is needed by the
      device_properties feature that Rafael is working on and planning to
      merge for v3.19. The implementation is identical both with and without
      the new static inline wrapper, so it just got left in to reduce the
      churn on the header file.
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darren Hart <darren.hart@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 20 Sep, 2014 1 commit
  4. 07 Jun, 2014 1 commit
  5. 22 Feb, 2014 1 commit
  6. 09 Jan, 2014 1 commit
    • Rob Herring's avatar
      Revert "of/address: Handle #address-cells > 2 specially" · 4fc7e470
      Rob Herring authored
      commit 13fcca8f25f4e9ce7f55da9cd353bb743236e212 upstream.
      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
      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.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 27 Sep, 2013 1 commit
  8. 29 Aug, 2013 1 commit
    • Wladislav Wiebe's avatar
      of: fdt: fix memory initialization for expanded DT · abcdf87c
      Wladislav Wiebe authored
      commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.
      Already existing property flags are filled wrong for properties created from
      initial FDT. This could cause problems if this DYNAMIC device-tree functions
      are used later, i.e. properties are attached/detached/replaced. Simply dumping
      flags from the running system show, that some initial static (not allocated via
      kzmalloc()) nodes are marked as dynamic.
      I putted some debug extensions to property_proc_show(..) :
      +       if (OF_IS_DYNAMIC(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
      +       if (OF_IS_DETACHED(pp))
      +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
      when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
      will see that those flags are filled wrong, basically in most cases it will dump
      a DYNAMIC or DETACHED status, which is in not true.
      (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
      make a test_bit(OF_DETACHED, &x->_flags)
      If nodes are dynamic kernel is allowed to kfree() them. But it will crash
      attempting to do so on the nodes from FDT -- they are not allocated via
      Signed-off-by: default avatarWladislav Wiebe <wladislav.kw@gmail.com>
      Acked-by: default avatarAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 25 Jul, 2013 1 commit
  10. 13 Jun, 2013 1 commit
  11. 08 May, 2013 1 commit
  12. 01 May, 2013 1 commit
  13. 17 Apr, 2013 2 commits
  14. 08 Apr, 2013 1 commit
  15. 04 Apr, 2013 2 commits
  16. 17 Feb, 2013 1 commit
    • Grant Likely's avatar
      Revert "of: use platform_device_add" · 02bbde78
      Grant Likely authored
      This reverts commit aac73f34. That
      commit causes two kinds of breakage; it breaks registration of AMBA
      devices when one of the parent nodes already contains overlapping
      resource regions, and it breaks calls to request_region() by device
      drivers in certain conditions where there are overlapping memory
      regions. Both of these problems can probably be fixed, but it is better
      to back out the commit and get a proper fix designed before trying again.
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
  17. 13 Feb, 2013 6 commits
  18. 08 Feb, 2013 1 commit
  19. 06 Feb, 2013 2 commits
    • Grant Likely's avatar
      of: use platform_device_add · aac73f34
      Grant Likely authored
      This allows platform_device_add a chance to call insert_resource on all
      of the resources from OF. At a minimum this fills in proc/iomem and
      presumably makes resource tracking and conflict detection work better.
      However, it has the side effect of moving all OF generated platform
      devices from /sys/devices to /sys/devices/platform/. It /shouldn't/
      break userspace because userspace is not supposed to depend on the full
      path (because userspace always does what it is supposed to, right?).
      This may cause breakage if either:
      1) any two nodes in a given device tree have overlapping & staggered
         regions (ie. 0x80..0xbf and 0xa0..0xdf; where one is not contained
         within the other). In this case one of the devices will fail to
         register and an exception will be needed in platform_device_add() to
         complain but not fail.
      2) any device calls request_mem_region() on a region larger than
         specified in the device tree. In this case the device node may be
         wrong, or the driver is overreaching. In either case I'd like to know
         about any problems and fix them.
      Please test. Despite the above, I'm still fairly confident that this
      patch is in good shape. I'd like to put it into linux-next, but would
      appreciate some bench testing from others before I do; particularly on
      PowerPC machines.
      v2: Remove powerpc special-case
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
    • Stepan Moskovchenko's avatar
      of: Output devicetree alias names in uevent · ced4eec9
      Stepan Moskovchenko authored
      In some situations, userspace may want to resolve a
      device by function and logical number (ie, "serial0")
      rather than by the base address or full device path. Being
      able to resolve a device by alias frees userspace from the
      burden of otherwise having to maintain a mapping between
      device addresses and their logical assignments on each
      platform when multiple instances of the same hardware block
      are present in the system.
      Although the uevent device attribute contains devicetree
      compatible information and the full device path, the uevent
      does not list the alises that may have been defined for the
      Signed-off-by: default avatarStepan Moskovchenko <stepanm@codeaurora.org>
      [grant.likely: Removed OF_ALIAS_N field; I don't think it's needed]
      [grant.likely: Added #ifndef _LINUX_OF_PRIVATE_H wrapper]
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
  20. 28 Jan, 2013 1 commit
    • Thomas Gleixner's avatar
      OF: Fixup resursive locking code paths · 28d0e36b
      Thomas Gleixner authored
      There is no real reason to use a rwlock for devtree_lock. It even
      could be a mutex, but unfortunately it's locked from cpu hotplug
      paths which can't schedule :(
      So it needs to become a raw lock on rt as well.  The devtree_lock would
      be the only user of a raw_rw_lock, so we are better off cleaning up the
      recursive locking paths which allows us to convert devtree_lock to a
      Here we do the standard thing of introducing __foo() as the "raw"
      version of foo(), so that we can take better control of the locking.
      The "raw" versions are not exported and are for internal use within
      the file itself.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
  21. 20 Jan, 2013 1 commit
  22. 14 Jan, 2013 1 commit
  23. 09 Jan, 2013 2 commits
  24. 08 Jan, 2013 2 commits
    • Jon Hunter's avatar
      of: dma: fix protection of DMA controller data stored by DMA helpers · 9743a3b6
      Jon Hunter authored
      In the current implementation of the OF DMA helpers, read-copy-update (RCU)
      linked lists are being used for storing and accessing the DMA controller data.
      This part of implementation is based upon V2 of the DMA helpers by Nicolas [1].
      During a recent review of RCU, it became apparent that the code is missing the
      required rcu_read_lock()/unlock() calls as well as synchronisation calls before
      freeing any memory protected by RCU.
      Having looked into adding the appropriate RCU calls to protect the DMA data it
      became apparent that with the current DMA helper implementation, using RCU is
      not as attractive as it may have been before. The main reasons being that ...
      1. We need to protect the DMA data around calls to the xlate function.
      2. The of_dma_simple_xlate() function calls the DMA engine function
         dma_request_channel() which employs a mutex and so could sleep.
      3. The RCU read-side critical sections must not sleep and so we cannot hold
         an RCU read lock around the xlate function.
      Therefore, instead of using RCU, an alternative for this use-case is to employ
      a simple spinlock inconjunction with a usage count variable to keep track of
      how many current users of the DMA data structure there are. With this
      implementation, the DMA data cannot be freed until all current users of the
      DMA data are finished.
      This patch is based upon the DMA helpers fix for potential deadlock [2].
      [1] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
      [2] http://marc.info/?l=linux-arm-kernel&m=134859982520984&w=2Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@linux.intel.com>
    • Jon Hunter's avatar
      of: dma: fix potential deadlock when requesting a slave channel · 5ca7c109
      Jon Hunter authored
      In the latest version of the OF dma handlers I added support (rather hastily)
      to exhaustively search for an available dma slave channel, for the use-case
      where we have alternative slave channels that can be used. In the current
      implementation a deadlock scenario can occur causing the CPU to loop forever.
      The scenario is as follows ...
      1. There are alternative channels avaialble
      2. The first channel that is found by calling of_dma_find_channel() is not
         available and so the call to the xlate function returns NULL. In this case
         we will call of_dma_find_channel() again but we will return the same channel
         that we found the first time and hence, again the xlate will return NULL and
         we will loop here forever.
      Fix this potential deadlock by just using a single for-loop and not a for-loop
      nested in a do-while loop. This change also replaces the function
      of_dma_find_channel() with of_dma_match_channel() which performs a simple check
      to see if a DMA channel matches the name specified.
      I have tested this implementation on an OMAP4 panda board by adding a dummy
      DMA specifier, that will cause the xlate function to return NULL, to the
      beginning of a list of DMA specifiers for a DMA client.
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <djbw@fb.com>
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@linux.intel.com>
  25. 07 Jan, 2013 1 commit
    • Jon Hunter's avatar
      of: Add generic device tree DMA helpers · aa3da644
      Jon Hunter authored
      This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
      to add some basic helpers to retrieve a DMA controller device_node and the
      DMA request/channel information.
      Aim of DMA helpers
      - The purpose of device-tree is to describe the capabilites of the hardware.
        Thinking about DMA controllers purely from the context of the hardware to
        begin with, we can describe a device in terms of a DMA controller as
        follows ...
        	1. Number of DMA controllers
      	2. Number of channels (maybe physical or logical)
      	3. Mapping of DMA requests signals to DMA controller
      	4. Number of DMA interrupts
      	5. Mapping of DMA interrupts to channels
      - With the above in mind the aim of the DT DMA helper functions is to extract
        the above information from the DT and provide to the appropriate driver.
        However, due to the vast number of DMA controllers and not all are using a
        common driver (such as DMA Engine) it has been seen that this is not a
        trivial task. In previous discussions on this topic the following concerns
        have been raised ...
      	1. How does the binding support devices with multiple DMA controllers?
        	2. How to support both legacy DMA controllers not using DMA Engine as
      	   well as those that support DMA Engine.
      	3. When using with DMA Engine how do we support the various
      	   implementations where the opaque filter function parameter differs
      	   between implementations?
      	4. How do we handle DMA channels that are identified with a string
      	   versus a integer?
      - Hence the design of the DMA helpers has to accomodate the above or align on
        an agreement what can be or should be supported.
      Design of DMA helpers
      1. Registering DMA controllers
         In the case of DMA controllers that are using DMA Engine, requesting a
         channel is performed by calling the following function.
      	struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
      			dma_filter_fn filter_fn,
      			void *filter_param);
         The mask variable is used to match a type of the device controller in a list
         of controllers. The filter_fn and filter_param are used to identify the
         required dma channel and return a handle to the dma channel of type dma_chan.
         From the examples I have seen, the mask and filter_fn are constant
         for a given DMA controller and therefore, we can specify these as controller
         specific data when registering the DMA controller with the device-tree DMA
         The filter_param variable is of an unknown type and is typically specific
         to the DMA engine implementation for a given DMA controller. To allow some
         flexibility in the type and formating of this filter_param we employ an
         xlate to translate the device-tree binding information into the appropriate
         format. The xlate function used for a DMA controller can also be specified
         when registering the DMA controller with the device-tree DMA helpers.
         Based upon the above, a function for registering the DMA controller with the
         DMA helpers now looks like the below. The data variable is used to pass a
         pointer to DMA controller specific data used by the xlate function.
      	int of_dma_controller_register(struct device_node *np,
      		struct dma_chan *(*of_dma_xlate)
      		(struct of_phandle_args *, struct of_dma *),
      		void *data)
         For example, in the case where DMA engine is used, we define the following
         structure (that stores the DMA engine capability mask and filter function)
         and pass this to the data variable in the above function.
      	struct of_dma_filter_info {
      		dma_cap_mask_t  dma_cap;
      		dma_filter_fn   filter_fn;
      2. Representing and requesting channel information
         Please see the dma binding documentation included in this patch for a
         description of how DMA controllers and client information should be
         represented with device-tree. For more information on how this binding
         came about please see [3]. In addition to this, feedback received from
         the Linux kernel summit showed a consensus (among those who attended) to
         use a name to identify DMA client information [4].
         A DMA channel can be requested by calling the following function, where name
         is a required parameter used for identifying a DMA channel. This function
         has been designed to return a structure of type dma_chan to work with the
         DMA engine driver. Note that if DMA engine is used then drivers should be
         using the DMA engine API dma_request_slave_channel() (implemented in part 2
         of this series, "dmaengine: add helper function to request a slave DMA
         channel") which will in turn call the below function if device-tree is
         present. The aim being to have a common DMA engine interface regardless of
         whether device tree is being used.
      	struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
      						      char *name)
      3. Supporting legacy devices not using DMA Engine
         These devices present a problem, as there may not be a uniform way to easily
         support them with regard to device tree. Ideally, these should be migrated
         to DMA engine. However, if this is not possible, then they should still be
         able to use this binding, the only constaint imposed by this implementation
         is that when requesting a DMA channel via of_dma_request_slave_channel(), it
         will return a type of dma_chan.
      This implementation has been tested on OMAP4430 using the kernel v3.6-rc5. I
      have validated that MMC is working on the PANDA board with this implementation.
      My development branch for testing on OMAP can be found here [5].
      v6: - minor corrections in DMA binding documentation
      v5: - minor update to binding documentation
          - added loop to exhaustively search for a slave channel in the case where
            there could be alternative channels available
      v4: - revert the removal of xlate function from v3
          - update the proposed binding format and APIs based upon discussions [3]
      v3: - avoid passing an xlate function and instead pass DMA engine parameters
          - define number of dma channels and requests in dma-controller node
      v2: - remove of_dma_to_resource API
          - make property #dma-cells required (no fallback anymore)
          - another check in of_dma_xlate_onenumbercell() function
      [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
      [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
      [3] http://marc.info/?l=linux-omap&m=133582085008539&w=2
      [4] http://pad.linaro.org/arm-mini-summit-2012
      [5] https://github.com/jonhunter/linux/tree/dev-dt-dma
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <djbw@fb.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Reviewed-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Acked-by: default avatarRob Herring <rob.herring@calxeda.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@linux.intel.com>
  26. 19 Dec, 2012 1 commit
  27. 18 Dec, 2012 1 commit
  28. 11 Dec, 2012 1 commit
  29. 07 Dec, 2012 1 commit
  30. 30 Nov, 2012 1 commit