1. 03 Feb, 2021 1 commit
    • Julius Werner's avatar
      qti: spmi_arb: Fix NUM_APID and REG_APID_MAP() argument · de67080f
      Julius Werner authored
      
      
      The NUM_APID value was derived from kernel device tree sources, but I
      made a conversion mistake: the amount of bytes in the APID map is the
      total size of the "core" register range (0x1100) minus the offset of the
      APID map in that range (0x900). This is of course 0x1100 - 0x900 = 0x800
      and not 0x200, so the amount of 4-byte integers it can fit is not 0x80
      but 0x200. Fix this and make the math more explicit so it can be more
      easily factored out and adjusted if that becomes necessary for a future
      SoC.
      
      Also fix a dangerous typo in REG_APID_MAP() where the macro would
      reference a random variable `i` rather than its argument (`apid`), and
      we just got lucky that the only caller in the current code happened to
      pass in a variable called `i` as that argument.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Change-Id: I049dd044fa5aeb65be0e7b12150afd6eb4bac0fa
      de67080f
  2. 27 Jan, 2021 3 commits
    • Lauren Wehrmeister's avatar
    • Madhukar Pappireddy's avatar
      Merge changes from topic "scmi-msg" into integration · 26dccba6
      Madhukar Pappireddy authored
      * changes:
        doc: maintainers: add scmi server
        drivers: move scmi-msg out of st
      26dccba6
    • Jimmy Brisson's avatar
      cert-tool: avoid duplicates in extension stack · 1ed941c0
      Jimmy Brisson authored
      
      
      This bug manifests itself as a segfault triggered by a double-free.
      
      I noticed that right before the double-free, the sk list contained 2
      elements with the same address.
      
          (gdb) p sk_X509_EXTENSION_value(sk, 1)
          $34 = (X509_EXTENSION *) 0x431ad0
          (gdb) p sk_X509_EXTENSION_value(sk, 0)
          $35 = (X509_EXTENSION *) 0x431ad0
          (gdb) p sk_X509_EXTENSION_num(sk)
          $36 = 2
      
      This caused confusion; this should never happen.
      
      I figured that this was caused by a ext_new_xxxx function freeing
      something before it is added to the list, so I put a breakpoint on
      each of them to step through. I was suprised to find that none of my
      breakpoints triggered for the second element of the iteration through
      the outer loop just before the double-free.
      
      Looking through the code, I noticed that it's possible to avoid doing
      a ext_new_xxxx, when either:
         * ext->type == NVCOUNTER and ext->arg == NULL
         * ext->type == HASH and ext->arg == NULL and ext->optional == false
      So I put a breakpoint on both.
      
      It turns out that it was the HASH version, but I added a fix for both.
      The fix for the Hash case is simple, as it was a mistake. The fix for
      the NVCOUNTER case, however, is a bit more subtle. The NVCOUNTER may
      be optional, and when it's optional we can skip it. The other case,
      when the NVCOUNTER is required (not optinal), the `check_cmd_params`
      function has already verified that the `ext->arg` must be non-NULL.
      We assert that before processing it to covert any possible segfaults
      into more descriptive errors.
      
      This should no longer cause double-frees by adding the same ext twice.
      
      Change-Id: Idae2a24ecd964b0a3929e6193c7f85ec769f6470
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      1ed941c0
  3. 26 Jan, 2021 2 commits
  4. 25 Jan, 2021 3 commits
  5. 24 Jan, 2021 1 commit
  6. 22 Jan, 2021 3 commits
  7. 21 Jan, 2021 3 commits
  8. 20 Jan, 2021 13 commits
  9. 19 Jan, 2021 7 commits
  10. 18 Jan, 2021 2 commits
    • Pali Rohár's avatar
      marvell: uart: a3720: Fix macro name for 6th bit of Status Register · b8e637f4
      Pali Rohár authored
      
      
      This patch does not change code, it only updates comments and macro name
      for 6th bit of Status Register. So TF-A binary stay same.
      
      6th bit of the Status Register is named TX EMPTY and is set to 1 when both
      Transmitter Holding Register (THR) or Transmitter Shift Register (TSR) are
      empty. It is when all characters were already transmitted.
      
      There is also TX FIFO EMPTY bit in the Status Register which is set to 1
      only when THR is empty.
      
      In both console_a3700_core_init() and console_a3700_core_flush() functions
      we should wait until both THR and TSR are empty therefore we should check
      6th bit of the Status Register.
      
      So current code is correct, just had misleading macro names and comments.
      This change fixes this "documentation" issue, fixes macro name for 6th bit
      of the Status Register and also updates comments.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Change-Id: I19e4e7f53a90bcfb318e6dd1b1249b6cbf81c4d3
      b8e637f4
    • Pali Rohár's avatar
      marvell: uart: a3720: Implement console_a3700_core_getc · 74867756
      Pali Rohár authored
      
      
      Implementation is simple, just check if there is a pending character in
      RX FIFO via RXRDY bit of Status Register and if yes, read it from
      UART_RX_REG register.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Change-Id: I226b6e336f44f5d0ca8dcb68e49a68e8f2f49708
      74867756
  11. 15 Jan, 2021 2 commits