1. 16 May, 2022 11 commits
  2. 15 May, 2022 2 commits
    • Mark Rutland's avatar
      arm64/sysreg: fix odd line spacing · 5005d1db
      Mark Rutland authored
      Between the header and the definitions, there's no line gap, and in a
      couple of places a double line gap for no semantic reason, which makes
      the output look a little odd.
      
      Fix this so blocks are consistently separated with a single line gap:
      
      * Add a newline after the "Generated file" comment line, so this is
        clearly split from whatever the first definition in the file is.
      
      * At the start of a SysregFields block there's no need for a newline as
        we haven't output any sysreg encoding details prior to this.
      
      * At the end of a Sysreg block there's no need for a newline if we
        have no RES0 or RES1 fields, as there will be a line gap after the
        previous element (e.g. a Fields line).
      
      There should be no functional change as a result of this patch.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20220513174118.266966-3-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      5005d1db
    • Mark Rutland's avatar
      arm64/sysreg: improve comment for regs without fields · 82bf5900
      Mark Rutland authored
      Currently for registers without fields we create a comment pointing at
      the common definitions, e.g.
      
      | #define REG_TTBR0_EL1                           S3_0_C2_C0_0
      | #define SYS_TTBR0_EL1                           sys_reg(3, 0, 2, 0, 0)
      | #define SYS_TTBR0_EL1_Op0                       3
      | #define SYS_TTBR0_EL1_Op1                       0
      | #define SYS_TTBR0_EL1_CRn                       2
      | #define SYS_TTBR0_EL1_CRm                       0
      | #define SYS_TTBR0_EL1_Op2                       0
      |
      | /* See TTBRx_EL1 */
      
      It would be slightly nicer if the comment said what we should be looking
      for, e.g.
      
      | #define REG_TTBR0_EL1                           S3_0_C2_C0_0
      | #define SYS_TTBR0_EL1                           sys_reg(3, 0, 2, 0, 0)
      | #define SYS_TTBR0_EL1_Op0                       3
      | #define SYS_TTBR0_EL1_Op1                       0
      | #define SYS_TTBR0_EL1_CRn                       2
      | #define SYS_TTBR0_EL1_CRm                       0
      | #define SYS_TTBR0_EL1_Op2                       0
      |
      | /* For TTBR0_EL1 fields see TTBRx_EL1 */
      
      Update the comment generation accordingly.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20220513174118.266966-2-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      82bf5900
  3. 06 May, 2022 1 commit
    • Mark Brown's avatar
      arm64/sme: More sensibly define the size for the ZA register set · d158a060
      Mark Brown authored
      Since the vector length configuration mechanism is identical between SVE
      and SME we share large elements of the code including the definition for
      the maximum vector length. Unfortunately when we were defining the ABI
      for SVE we included not only the actual maximum vector length of 2048
      bits but also the value possible if all the bits reserved in the
      architecture for expansion of the LEN field were used, 16384 bits.
      
      This starts creating problems if we try to allocate anything for the ZA
      matrix based on the maximum possible vector length, as we do for the
      regset used with ptrace during the process of generating a core dump.
      While the maximum potential size for ZA with the current architecture is
      a reasonably managable 64K with the higher reserved limit ZA would be
      64M which leads to entirely reasonable complaints from the memory
      management code when we try to allocate a buffer of that size. Avoid
      these issues by defining the actual maximum vector length for the
      architecture and using it for the SME regsets.
      
      Also use the full ZA_PT_SIZE() with the header rather than just the
      actual register payload when specifying the size, fixing support for the
      largest vector lengths now that we have this new, lower define. With the
      SVE maximum this did not cause problems due to the extra headroom we
      had.
      
      While we're at it add a comment clarifying why even though ZA is a
      single register we tell the regset code that it is a multi-register
      regset.
      Reported-by: default avatarQian Cai <quic_qiancai@quicinc.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Tested-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Link: https://lore.kernel.org/r/20220505221517.1642014-1-broonie@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      d158a060
  4. 04 May, 2022 12 commits
  5. 29 Apr, 2022 1 commit
  6. 27 Apr, 2022 1 commit
  7. 22 Apr, 2022 12 commits