1. 11 Jan, 2022 4 commits
  2. 09 Jan, 2022 7 commits
  3. 05 Jan, 2022 5 commits
  4. 02 Jan, 2022 11 commits
  5. 21 Dec, 2021 3 commits
  6. 16 Dec, 2021 10 commits
    • Ye Guojin's avatar
      MIPS: OCTEON: add put_device() after of_find_device_by_node() · 858779df
      Ye Guojin authored
      This was found by coccicheck:
      ./arch/mips/cavium-octeon/octeon-platform.c, 332, 1-7, ERROR missing
      put_device; call of_find_device_by_node on line 324, but without a
      corresponding object release within this function.
      ./arch/mips/cavium-octeon/octeon-platform.c, 395, 1-7, ERROR missing
      put_device; call of_find_device_by_node on line 387, but without a
      corresponding object release within this function.
      ./arch/mips/cavium-octeon/octeon-usb.c, 512, 3-9, ERROR missing
      put_device; call of_find_device_by_node on line 515, but without a
      corresponding object release within this function.
      ./arch/mips/cavium-octeon/octeon-usb.c, 543, 1-7, ERROR missing
      put_device; call of_find_device_by_node on line 515, but without a
      corresponding object release within this function.
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Signed-off-by: default avatarYe Guojin <ye.guojin@zte.com.cn>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      858779df
    • Jason Wang's avatar
      MIPS: BCM47XX: Replace strlcpy with strscpy · 906c6bc6
      Jason Wang authored
      The strlcpy should not be used because it doesn't limit the source
      length. As linus says, it's a completely useless function if you
      can't implicitly trust the source string - but that is almost always
      why people think they should use it! All in all the BSD function
      will lead some potential bugs.
      
      But the strscpy doesn't require reading memory from the src string
      beyond the specified "count" bytes, and since the return value is
      easier to error-check than strlcpy()'s. In addition, the implementation
      is robust to the string changing out from underneath it, unlike the
      current strlcpy() implementation.
      
      Thus, We prefer using strscpy instead of strlcpy.
      Signed-off-by: default avatarJason Wang <wangborong@cdjrlc.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      906c6bc6
    • Lukas Bulwahn's avatar
      mips: fix Kconfig reference to PHYS_ADDR_T_64BIT · a670c82d
      Lukas Bulwahn authored
      Commit d4a451d5 ("arch: remove the ARCH_PHYS_ADDR_T_64BIT config
      symbol") removes config ARCH_PHYS_ADDR_T_64BIT with all instances of that
      config refactored appropriately. Since then, it is recommended to use the
      config PHYS_ADDR_T_64BIT instead.
      
      Commit 171543e7 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
      introduces the expression "!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))"
      for config CPU_SUPPORTS_HUGEPAGES, which unintentionally refers to the
      non-existing symbol ARCH_PHYS_ADDR_T_64BIT instead of the intended
      PHYS_ADDR_T_64BIT.
      
      Fix this Kconfig reference to the intended PHYS_ADDR_T_64BIT.
      
      This issue was identified with the script ./scripts/checkkconfigsymbols.py.
      I then reported it on the mailing list and Paul confirmed the mistake in
      the linked email thread.
      
      Link: https://lore.kernel.org/lkml/H8IU3R.H5QVNRA077PT@crapouillou.net/Suggested-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Fixes: 171543e7 ("MIPS: Disallow CPU_SUPPORTS_HUGEPAGES for XPA,EVA")
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      a670c82d
    • Lukas Bulwahn's avatar
      mips: txx9: remove left-over for removed TXX9_ACLC configs · ddc18bd7
      Lukas Bulwahn authored
      The patch series "Remove support for TX49xx" (see Link) was only partially
      applied: The ASoC driver was removed with commit a8644292 ("ASoC:
      txx9: Remove driver"), which was patch 10/10 from that series. The mips
      architecture code to be removed with patch 1/10 from that series was not
      applied.
      
      This partial patch series application leaves the build config setup and
      code in the mips architecture in a slightly unclean, intermediate state.
      The configs HAS_TXX9_ACLC and SND_SOC_TXX9ACLC were removed, but are still
      referenced in the txx9-architecture Kconfig and generic setup.
      
      The script ./scripts/checkkconfigsymbols.py warns about this:
      
        HAS_TXX9_ACLC
        Referencing files: arch/mips/txx9/Kconfig
      
        SND_SOC_TXX9ACLC
        Referencing files: arch/mips/txx9/generic/setup.c
      
      Clean up the code for those removed references.
      
      Link: https://lore.kernel.org/all/20210105140305.141401-1-tsbogend@alpha.franken.de/Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      ddc18bd7
    • Lukas Bulwahn's avatar
      mips: alchemy: remove historic comment on gpio build constraints · a51f0824
      Lukas Bulwahn authored
      In ./arch/mips/alchemy/common/gpiolib.c, the comment points out certain
      build constraints on CONFIG_GPIOLIB and CONFIG_ALCHEMY_GPIO_INDIRECT.
      
      The commit 832f5dac ("MIPS: Remove all the uses of custom gpio.h")
      makes all mips machines use the common gpio.h and removes the config
      ALCHEMY_GPIO_INDIRECT. So, this makes the comment in alchemy's gpiolib.c
      historic and obsolete, and can be removed after the commit above.
      
      The issue on the reference to a non-existing Kconfig symbol was identified
      with ./scripts/checkkconfigsymbols.py. This script has been quite useful
      to identify a number of bugs with Kconfig symbols and deserves to be
      executed and checked regularly.
      
      So, remove the historic comment to reduce the reports made the script and
      simplify to use this script, as new issues are easier to spot when the
      list of reports is shorter.
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      a51f0824
    • Lukas Bulwahn's avatar
      mips: remove obsolete selection of CPU_HAS_LOAD_STORE_LR · bb900d43
      Lukas Bulwahn authored
      Commit 18d84e2e ("MIPS: make CPU_HAS_LOAD_STORE_LR opt-out") replaced
      the config CPU_HAS_LOAD_STORE_LR by the config with an inverted semantics,
      making the "LOAD_STORE_LR" cpu configuration the default.
      The ./arch/mips/Kconfig was adjusted accordingly.
      
      Later, commit 65ce6197 ("Revert "MIPS: Remove unused R4300 CPU
      support"") reintroduces a select CPU_HAS_LOAD_STORE_LR through its revert
      commit, restoring the config CPU_R4300 in ./arch/mips/Kconfig before the
      refactoring above.
      
      This select however now refers to a non-existing config and is further
      unneeded, as LOAD_STORE_LR is the default now.
      
      Remove the obsolete select for the reintroduced mips R4300 architecture.
      
      This issue is identified with ./scripts/checkkconfigsymbols.py.
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      bb900d43
    • Lukas Bulwahn's avatar
      mips: kgdb: adjust the comment to the actual ifdef condition · 301e4999
      Lukas Bulwahn authored
      The comment refers to CONFIG_CPU_32BIT, but the ifdef uses CONFIG_32BIT.
      As this ifdef and comment was introduced with initial mips-kgdb commit
      88547001 ("[MIPS] kgdb: add arch support for the kernel's kgdb core"),
      it is probably just a minor issue that was overlooked during the patch
      creation and refactoring before submission.
      
      This inconsistency was identified with ./scripts/checkkconfigsymbols.py.
      This script has been quite useful to identify a number of bugs with
      Kconfig symbols and deserves to be executed and checked regularly.
      
      So, adjust the comment to the actual ifdef condition to reduce the
      reports made the script and simplify to use this script, as new issues
      are easier to spot when the list of reports is shorter.
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      301e4999
    • Lukas Bulwahn's avatar
      mips: dec: provide the correctly capitalized config CPU_R4X00 in init error message · 9a53a8d7
      Lukas Bulwahn authored
      The config for MIPS R4000-series processors is named CPU_R4X00 with
      upper-case X, not CPU_R4x00 as the error message suggests.
      
      Hence, ./scripts/checkkconfigsymbols.py reports this invalid reference:
      
        CPU_R4x00
        Referencing files: arch/mips/dec/prom/init.c
      
      When human users encounter this error message, they probably just deal
      with this minor discrepancy; so, the spelling never was a big deal here.
      
      Still, the script ./scripts/checkkconfigsymbols.py has been quite useful
      to identify a number of bugs with Kconfig symbols and deserves to be
      executed and checked regularly.
      
      So, repair the error message to reduce the reports made the script and
      simplify to use this script, as new issues are easier to spot when the
      list of reports is shorter.
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      9a53a8d7
    • Lukas Bulwahn's avatar
      mips: drop selecting non-existing config NR_CPUS_DEFAULT_2 · 74320247
      Lukas Bulwahn authored
      Commit c5eaff3e ("MIPS: Kconfig: Drop obsolete NR_CPUS_DEFAULT_{1,2}
      options") removed the config NR_CPUS_DEFAULT_2, as with this commit, the
      NR_CPUS default value is 2.
      
      Commit 7505576d ("MIPS: add support for SGI Octane (IP30)") introduces
      the config SGI_IP30, which selects the removed config NR_CPUS_DEFAULT_2,
      but this has actually no effect.
      
      Fortunately, NR_CPUS defaults to 2 when there is no specific
      NR_CPUS_DEFAULT_* config selected. So, the effect of the intended
      'select NR_CPUS_DEFAULT_2' is achieved without further ado.
      
      Drop selecting the non-existing config NR_CPUS_DEFAULT_2.
      
      The issue was identified with ./scripts/checkkconfigsymbols.py.
      
      Fixes: 7505576d ("MIPS: add support for SGI Octane (IP30)")
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      74320247
    • Lukas Bulwahn's avatar
      mips: add SYS_HAS_CPU_MIPS64_R5 config for MIPS Release 5 support · fd4eb90b
      Lukas Bulwahn authored
      Commit ab7c01fd ("mips: Add MIPS Release 5 support") adds the two
      configs CPU_MIPS32_R5 and CPU_MIPS64_R5, which depend on the corresponding
      SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R5, respectively.
      
      The config SYS_HAS_CPU_MIPS32_R5 was already introduced with commit
      c5b36783 ("MIPS: Add support for XPA."); the config
      SYS_HAS_CPU_MIPS64_R5, however, was never introduced.
      
      Hence, ./scripts/checkkconfigsymbols.py warns:
      
        SYS_HAS_CPU_MIPS64_R5
        Referencing files: arch/mips/Kconfig, arch/mips/include/asm/cpu-type.h
      
      Add the definition for config SYS_HAS_CPU_MIPS64_R5 under the assumption
      that SYS_HAS_CPU_MIPS64_R5 follows the same pattern as the existing
      SYS_HAS_CPU_MIPS32_R5 and SYS_HAS_CPU_MIPS64_R6.
      
      Fixes: ab7c01fd ("mips: Add MIPS Release 5 support")
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      fd4eb90b