1. 18 11月, 2016 1 次提交
    • S
      of: base: add support to get machine model name · e5269794
      Sudeep Holla 提交于
      Currently platforms/drivers needing to get the machine model name are
      replicating the same snippet of code. In some case, the OF reference
      counting is either missing or incorrect.
      
      This patch adds support to read the machine model name either using
      the "model" or the "compatible" property in the device tree root node
      to the core OF/DT code.
      
      This can be used to remove all the duplicate code snippets doing exactly
      same thing later.
      
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      e5269794
  2. 08 10月, 2016 1 次提交
    • P
      console: don't prefer first registered if DT specifies stdout-path · 05fd007e
      Paul Burton 提交于
      If a device tree specifies a preferred device for kernel console output
      via the stdout-path or linux,stdout-path chosen node properties or the
      stdout alias then the kernel ought to honor it & output the kernel
      console to that device.  As it stands, this isn't the case.  Whilst we
      parse the stdout-path properties & set an of_stdout variable from
      of_alias_scan(), and use that from of_console_check() to determine
      whether to add a console device as a preferred console whilst
      registering it, we also prefer the first registered console if no other
      has been selected at the time of its registration.
      
      This means that if a console other than the one the device tree selects
      via stdout-path is registered first, we will switch to using it & when
      the stdout-path console is later registered the call to
      add_preferred_console() via of_console_check() is too late to do
      anything useful.  In practice this seems to mean that we switch to the
      dummy console device fairly early & see no further console output:
      
          Console: colour dummy device 80x25
          console [tty0] enabled
          bootconsole [ns16550a0] disabled
      
      Fix this by not automatically preferring the first registered console if
      one is specified by the device tree.  This allows consoles to be
      registered but not enabled, and once the driver for the console selected
      by stdout-path calls of_console_check() the driver will be added to the
      list of preferred consoles before any other console has been enabled.
      When that console is then registered via register_console() it will be
      enabled as expected.
      
      Link: http://lkml.kernel.org/r/20160809151937.26118-1-paul.burton@imgtec.comSigned-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ivan Delalande <colona@arista.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05fd007e
  3. 15 9月, 2016 2 次提交
    • R
      of: Add array read functions with min/max size limits · a67e9472
      Richard Fitzgerald 提交于
      Add a new set of array reading functions that take a minimum and
      maximum size limit and will fail if the property size is not within
      the size limits. This makes it more convenient for drivers that
      use variable-size DT arrays which must be bounded at both ends -
      data must be at least N entries but must not overflow the array
      it is being copied into. It is also more efficient than making this
      functionality out of existing public functions and avoids duplication.
      
      The existing array functions have been left in the API, since there
      are a very large number of clients of those functions and their
      existing functionality is still useful. This avoids turning a small
      API improvement into a major kernel rework.
      
      The old functions have been turned into mininmal static inlines calling
      the new functions. The old functions had no upper limit on the actual
      size of the dts entry, to preserve this functionality rather than keeping
      two near-identical implementations, if the new function is called with
      max=0 there is no limit on the size of the dts entry but only the min
      number of elements are read.
      Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      a67e9472
    • R
      of: Make of_find_property_value_of_size take a length range · 79ac5d31
      Richard Fitzgerald 提交于
      In preparation for adding variable-length array reads, change
      of_find_property_value_of_size so that it takes an optional
      maximum length. If the maximum is passed as 0, the behaviour is
      unchanged and it will return a property if it's >= the requested
      minimum length. If maximum is non-zero it will only return a
      property whose length is min <= l <= max.
      Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      79ac5d31
  4. 16 8月, 2016 1 次提交
  5. 10 8月, 2016 1 次提交
  6. 20 7月, 2016 1 次提交
  7. 19 7月, 2016 1 次提交
  8. 25 6月, 2016 1 次提交
    • F
      of: fix memory leak related to safe_name() · d9fc8807
      Frank Rowand 提交于
      Fix a memory leak resulting from memory allocation in safe_name().
      This patch fixes all call sites of safe_name().
      
      Mathieu Malaterre reported the memory leak on boot:
      
      On my PowerMac device-tree would generate a duplicate name:
      
      [    0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1"
      
      in this case a newly allocated name is generated by `safe_name`. However
      in this case it is never deallocated.
      
      The bug was found using kmemleak reported as:
      
      unreferenced object 0xdf532e60 (size 32):
        comm "swapper", pid 1, jiffies 4294892300 (age 1993.532s)
        hex dump (first 32 bytes):
          6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2  l2-cache#1......
          ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e  ................
        backtrace:
          [<c02d3350>] kvasprintf+0x64/0xc8
          [<c02d3400>] kasprintf+0x4c/0x5c
          [<c0453814>] safe_name.isra.1+0x80/0xc4
          [<c04545d8>] __of_attach_node_sysfs+0x6c/0x11c
          [<c075f21c>] of_core_init+0x8c/0xf8
          [<c0729594>] kernel_init_freeable+0xd4/0x208
          [<c00047e8>] kernel_init+0x24/0x11c
          [<c00158ec>] ret_from_kernel_thread+0x5c/0x64
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331Signed-off-by: NFrank Rowand <frank.rowand@am.sony.com>
      Reported-by: mathieu.malaterre@gmail.com
      Tested-by: NMathieu Malaterre <mathieu.malaterre@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRob Herring <robh@kernel.org>
      d9fc8807
  9. 11 5月, 2016 1 次提交
    • S
      drivers/of: Add check for null property in of_remove_property() · 201b3fe5
      Suraj Jitindar Singh 提交于
      The validity of the property input argument to of_remove_property() is
      never checked within the function and thus it is possible to pass a null
      value. It happens that this will be picked up in __of_remove_property()
      as no matching property of the device node will be found and thus an
      error will be returned, however once again there is no explicit check
      for a null value. By the time this is detected 2 locks have already been
      acquired which is completely unnecessary if the property to remove is
      null.
      
      Add an explicit check in the function of_remove_property() for a null
      property value and return -ENODEV in this case, this is consistent with
      what the previous return value would have been when the null value was
      not detected and passed to __of_remove_property().
      
      By moving an explicit check for the property paramenter into the
      of_remove_property() function, this will remove the need to perform this
      check in calling code before invocation of the of_remove_property()
      function.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      201b3fe5
  10. 25 4月, 2016 1 次提交
  11. 20 4月, 2016 5 次提交
  12. 04 3月, 2016 1 次提交
  13. 31 10月, 2015 1 次提交
  14. 23 6月, 2015 1 次提交
  15. 22 6月, 2015 1 次提交
  16. 04 6月, 2015 1 次提交
  17. 27 5月, 2015 1 次提交
  18. 25 5月, 2015 1 次提交
  19. 17 4月, 2015 1 次提交
  20. 15 4月, 2015 1 次提交
    • K
      of: Add helper function to check MMIO register endianness · 37786c7f
      Kevin Cernekee 提交于
      SoC peripherals can come in several different flavors:
      
       - little-endian: registers always need to be accessed in LE mode (so the
         kernel should perform a swap if the CPU is running BE)
      
       - big-endian: registers always need to be accessed in BE mode (so the
         kernel should perform a swap if the CPU is running LE)
      
       - native-endian: the bus will automatically swap accesses, so the kernel
         should never swap
      
      Introduce a function that checks an OF device node to see whether it
      contains a "big-endian" or "native-endian" property.  For the former case,
      always return true.  For the latter case, return true iff the kernel was
      built for BE (implying that the BE MMIO accessors do not perform a swap).
      Otherwise return false, assuming LE registers.
      
      LE registers are assumed by default because most existing drivers (libahci,
      serial8250, usb) always use readl/writel in the absence of instructions
      to the contrary, so that will be our fallback.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NRob Herring <robh@kernel.org>
      37786c7f
  21. 19 3月, 2015 2 次提交
  22. 18 3月, 2015 1 次提交
  23. 10 3月, 2015 2 次提交
  24. 23 2月, 2015 2 次提交
  25. 04 2月, 2015 1 次提交
  26. 04 12月, 2014 2 次提交
  27. 28 11月, 2014 1 次提交
  28. 19 11月, 2014 2 次提交
  29. 05 11月, 2014 2 次提交