Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 8月, 2013 2 次提交
  3. 22 8月, 2013 1 次提交
    • W
      of: fdt: fix memory initialization for expanded DT · 9e401275
      由 Wladislav Wiebe 提交于 
      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
kzmalloc().
Signed-off-by: NWladislav Wiebe <wladislav.kw@gmail.com>
Acked-by: NAlexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      9e401275
  5. 24 7月, 2013 2 次提交
  7. 23 7月, 2013 2 次提交
  9. 04 7月, 2013 1 次提交
  11. 18 6月, 2013 1 次提交
  13. 14 6月, 2013 1 次提交
  15. 12 6月, 2013 2 次提交
  17. 01 6月, 2013 1 次提交
  19. 20 5月, 2013 3 次提交
  21. 09 5月, 2013 1 次提交
  23. 02 5月, 2013 1 次提交
  25. 17 4月, 2013 2 次提交
  27. 09 4月, 2013 1 次提交
  29. 04 4月, 2013 2 次提交
  31. 18 2月, 2013 1 次提交
    • G
      Revert "of: use platform_device_add" · 02bbde78
      由 Grant Likely 提交于 
      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: NGrant Likely <grant.likely@secretlab.ca>
      02bbde78
  33. 14 2月, 2013 1 次提交
  35. 13 2月, 2013 5 次提交
  37. 09 2月, 2013 1 次提交
  39. 06 2月, 2013 2 次提交
    • G
      of: use platform_device_add · aac73f34
      由 Grant Likely 提交于 
      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: NGrant Likely <grant.likely@secretlab.ca>
      aac73f34
    • S
      of: Output devicetree alias names in uevent · ced4eec9
      由 Stepan Moskovchenko 提交于 
      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
device.
Signed-off-by: NStepan 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: NGrant Likely <grant.likely@secretlab.ca>
      ced4eec9
  41. 28 1月, 2013 1 次提交
    • T
      OF: Fixup resursive locking code paths · 28d0e36b
      由 Thomas Gleixner 提交于 
      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
read_lock.

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: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      28d0e36b
  43. 21 1月, 2013 1 次提交
  45. 15 1月, 2013 1 次提交
  47. 09 1月, 2013 2 次提交
  49. 08 1月, 2013 2 次提交
    • J
      of: dma: fix protection of DMA controller data stored by DMA helpers · 9743a3b6
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      9743a3b6
    • J
      of: dma: fix potential deadlock when requesting a slave channel · 5ca7c109
      由 Jon Hunter 提交于 
      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: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      5ca7c109