1. Oct 03, 2022
  2. Oct 01, 2022
  3. Sep 30, 2022
  4. Sep 27, 2022
  5. Sep 26, 2022
  6. Sep 17, 2022
  7. Sep 14, 2022
  8. Sep 13, 2022
  9. Sep 10, 2022
  10. Sep 09, 2022
    • Luca Weiss's avatar
      dt-bindings: qcom,pdc: convert to YAML · 13ef76d8
      Luca Weiss authored
      
      
      Convert the PDC interrupt controller bindings to YAML.
      
      Signed-off-by: default avatarLuca Weiss <luca.weiss@fairphone.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20220103074348.6039-1-luca.weiss@fairphone.com
      
      
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      13ef76d8
    • Marek Bykowski's avatar
      of/fdt: Don't calculate initrd size from DT if start > end · d5e3050c
      Marek Bykowski authored
      
      
      If the properties 'linux,initrd-start' and 'linux,initrd-end' of
      the chosen node populated from the bootloader, eg. U-Boot, are so that
      start > end, then the phys_initrd_size calculated from end - start is
      negative that subsequently gets converted to a high positive value for
      being unsigned long long. Then, the memory region with the (invalid)
      size is added to the bootmem and attempted being paged in paging_init()
      that results in the kernel fault.
      
      For example, on the FVP ARM64 system I'm running, the U-Boot populates
      the 'linux,initrd-start' with 8800_0000 and 'linux,initrd-end' with 0.
      The phys_initrd_size calculated is then ffff_ffff_7800_0000
      (= 0 - 8800_0000 = -8800_0000 + ULLONG_MAX + 1). paging_init() then
      attempts to map the address 8800_0000 + ffff_ffff_7800_0000 and oops'es
      as below.
      
      It should be stressed, it is generally a fault of the bootloader's with
      the kernel relying on it, however we should not allow the bootloader's
      misconfiguration to lead to the kernel oops. Not only the kernel should be
      bullet proof against it but also finding the root cause of the paging
      fault spanning over the bootloader, DT, and kernel may happen is not so
      easy.
      
        Unable to handle kernel paging request at virtual address fffffffefe43c000
        Mem abort info:
          ESR = 0x96000007
          EC = 0x25: DABT (current EL), IL = 32 bits
          SET = 0, FnV = 0
          EA = 0, S1PTW = 0
        Data abort info:
          ISV = 0, ISS = 0x00000007
          CM = 0, WnR = 0
        swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
        [fffffffefe43c000] pgd=0000000080de9003, pud=0000000080de9003
        Unable to handle kernel paging request at virtual address ffffff8000de9f90
        Mem abort info:
          ESR = 0x96000005
          EC = 0x25: DABT (current EL), IL = 32 bits
          SET = 0, FnV = 0
          EA = 0, S1PTW = 0
        Data abort info:
          ISV = 0, ISS = 0x00000005
          CM = 0, WnR = 0
        swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000
        [ffffff8000de9f90] pgd=0000000000000000, pud=0000000000000000
        Internal error: Oops: 96000005 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.51-yocto-standard #1
        Hardware name: FVP Base (DT)
        pstate: 60000085 (nZCv daIf -PAN -UAO)
        pc : show_pte+0x12c/0x1b4
        lr : show_pte+0x100/0x1b4
        sp : ffffffc010ce3b30
        x29: ffffffc010ce3b30 x28: ffffffc010ceed80
        x27: fffffffefe43c000 x26: fffffffefe43a028
        x25: 0000000080bf0000 x24: 0000000000000025
        x23: ffffffc010b8d000 x22: ffffffc010e3d000
        x23: ffffffc010b8d000 x22: ffffffc010e3d000
        x21: 0000000080de9000 x20: ffffff7f80000f90
        x19: fffffffefe43c000 x18: 0000000000000030
        x17: 0000000000001400 x16: 0000000000001c00
        x15: ffffffc010cef1b8 x14: ffffffffffffffff
        x13: ffffffc010df1f40 x12: ffffffc010df1b70
        x11: ffffffc010ce3b30 x10: ffffffc010ce3b30
        x9 : 00000000ffffffc8 x8 : 0000000000000000
        x7 : 000000000000000f x6 : ffffffc010df16e8
        x5 : 0000000000000000 x4 : 0000000000000000
        x3 : 00000000ffffffff x2 : 0000000000000000
        x1 : 0000008080000000 x0 : ffffffc010af1d68
        Call trace:
         show_pte+0x12c/0x1b4
         die_kernel_fault+0x54/0x78
         __do_kernel_fault+0x11c/0x128
         do_translation_fault+0x58/0xac
         do_mem_abort+0x50/0xb0
         el1_da+0x1c/0x90
         __create_pgd_mapping+0x348/0x598
         paging_init+0x3f0/0x70d0
         setup_arch+0x2c0/0x5d4
         start_kernel+0x94/0x49c
        Code: 92748eb5 900052a0 9135a000 cb010294 (f8756a96) 
      
      Signed-off-by: default avatarMarek Bykowski <marek.bykowski@gmail.com>
      Link: https://lore.kernel.org/r/20220909023358.76881-1-marek.bykowski@gmail.com
      
      
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      d5e3050c
    • Olliver Schinagl's avatar
      dt-bindings: leds: Expand LED_COLOR_ID definitions · 472d7b9e
      Olliver Schinagl authored
      In commit 853a78a7 (dt-bindings: leds: Add LED_COLOR_ID definitions,
      Sun Jun 9 20:19:04 2019 +0200) the most basic color definitions where
      added. However, there's a little more very common LED colors.
      
      While the documentation states 'add what is missing', engineers tend to
      be lazy and will just use what currently exists. So this patch will take
      (a) list from online retailers [0], [1], [2] and use the common LED colors from
      there, this being reasonable as this is what is currently available to purchase.
      
      Note, that LIME seems to be the modern take to 'Yellow-green' or
      'Yellowish-green' from some older datasheets.
      
      [0]: https://www.digikey.com/en/products/filter/led-lighting-color/125
      [1]: https://eu.mouser.com/c/optoelectronics/led-lighting/led-emitters/standard-leds-smd
      [2]: https://nl.farnell.com/en-NL/c/optoelectronics-displays/led-products/standard-single-colour-leds-under-75ma
      
      
      
      Signed-off-by: default avatarOlliver Schinagl <oliver@schinagl.nl>
      Acked-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Acked-by: default avatarAlexander Dahl <ada@thorsis.com>
      Acked-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      Link: https://lore.kernel.org/r/20220830134613.1564059-1-oliver@schinagl.nl
      
      
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      472d7b9e
  11. Sep 08, 2022
  12. Sep 07, 2022
  13. Sep 01, 2022
  14. Aug 30, 2022