1. 08 Oct, 2016 1 commit
    • Paul Burton's avatar
      console: don't prefer first registered if DT specifies stdout-path · 05fd007e
      Paul Burton authored
      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.com
      Signed-off-by: default avatarPaul 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 15 Sep, 2016 2 commits
    • Richard Fitzgerald's avatar
      of: Add array read functions with min/max size limits · a67e9472
      Richard Fitzgerald authored
      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: default avatarRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
    • Richard Fitzgerald's avatar
      of: Make of_find_property_value_of_size take a length range · 79ac5d31
      Richard Fitzgerald authored
      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: default avatarRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  3. 15 Aug, 2016 1 commit
  4. 09 Aug, 2016 1 commit
  5. 20 Jul, 2016 1 commit
  6. 18 Jul, 2016 1 commit
  7. 24 Jun, 2016 1 commit
    • Frank Rowand's avatar
      of: fix memory leak related to safe_name() · d9fc8807
      Frank Rowand authored
      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  ................
          [<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=120331
      Signed-off-by: default avatarFrank Rowand <frank.rowand@am.sony.com>
      Reported-by: mathieu.malaterre@gmail.com
      Tested-by: default avatarMathieu Malaterre <mathieu.malaterre@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  8. 11 May, 2016 1 commit
    • Suraj Jitindar Singh's avatar
      drivers/of: Add check for null property in of_remove_property() · 201b3fe5
      Suraj Jitindar Singh authored
      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
      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()
      Signed-off-by: default avatarSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  9. 25 Apr, 2016 1 commit
  10. 19 Apr, 2016 5 commits
  11. 03 Mar, 2016 1 commit
  12. 30 Oct, 2015 1 commit
  13. 23 Jun, 2015 1 commit
  14. 22 Jun, 2015 1 commit
  15. 04 Jun, 2015 1 commit
  16. 27 May, 2015 1 commit
  17. 24 May, 2015 1 commit
  18. 17 Apr, 2015 1 commit
  19. 15 Apr, 2015 1 commit
    • Kevin Cernekee's avatar
      of: Add helper function to check MMIO register endianness · 37786c7f
      Kevin Cernekee authored
      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: default avatarKevin Cernekee <cernekee@gmail.com>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  20. 19 Mar, 2015 2 commits
  21. 18 Mar, 2015 1 commit
  22. 10 Mar, 2015 2 commits
  23. 23 Feb, 2015 2 commits
  24. 04 Feb, 2015 1 commit
  25. 03 Dec, 2014 2 commits
  26. 27 Nov, 2014 1 commit
  27. 18 Nov, 2014 2 commits
  28. 04 Nov, 2014 3 commits