1. 11 Sep, 2021 6 commits
  2. 09 Sep, 2021 1 commit
    • Tom Rini's avatar
      Merge branch '2021-09-08-fix-FIT-hash-algos-in-SPL' · 4412fd8b
      Tom Rini authored
      - Merge some fixes to how we enable hash algorithms for FIT images in
        SPL.  This fixes a few cases where we should have had some options
        enabled, but did not.  This also removes otherwise unused options in a
        few other cases.
  3. 08 Sep, 2021 6 commits
    • Alexandru Gagniuc's avatar
      image: Drop IMAGE_ENABLE_{MD5, CRC32} #defines · 0b905e25
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      These are no longer used, so drop them.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
    • Alexandru Gagniuc's avatar
      image: Drop if/elseif hash selection in calculate_hash() · 92055e13
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      calculate_hash() would try to select the appropriate hashing function
      by a if/elseif contruct. But that is exactly why hash_lookup_algo()
      exists, so use it instead.
      This does mean that we now have to 'select HASH' to make sure we get
      the hash_lookup_algo() symbol. However, the change makes sense because
      even basic FITs will have to deal with "hash" nodes.
      My only concern is that the 'select SPL_HASH' might cause some
      platform to grow above its SPL size allowance
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Make FSL_CAAM be implied only on ARM && SPL]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
    • Alexandru Gagniuc's avatar
      common: Move MD5 hash to hash_algo[] array. · fe54aeaa
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      MD5 is being called directly in some places, but it is not available
      via hash_lookup_algo("md5"). This is inconsistent with other hasing
      routines. To resolve this, add an "md5" entry to hash_algos[].
      The #ifdef clause looks funnier than those for other entries. This is
      because both MD5 and SPL_MD5 configs exist, whereas the other hashes
      do not have "SPL_" entries. The long term plan is to get rid of the
      ifdefs, so those should not be expected to survive much longer.
      The md5 entry does not have .hash_init/update/finish members. That's
      okay because hash_progressive_lookup_algo() will catch that, and
      return -EPROTONOSUPPORT, while hash_lookup_algo() will return the
      correct pointer.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Use CONFIG_IS_ENABLED not IS_ENABLED for MD5 check]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
    • Alexandru Gagniuc's avatar
      common/spl: Drop [ST]PL_HASH_SUPPORT in favor of [ST]PL_HASH · 07212096
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      All of these configs exist. Stick to using CONFIG_[ST]PL_HASH, and drop all
      references to CONFIG_[ST]PL_HASH_SUPPORT.  This means we need for
      CHAIN_OF_TRUST to select SPL_HASH now.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Add TPL case, fix CHAIN_OF_TRUST, other tweaks]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
    • Alexandru Gagniuc's avatar
      lib: Drop SHA512_ALGO in lieu of SHA512 · e60e4499
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      SHA512_ALGO was used as a "either SHA512 or SHA384", although the
      implementations of these two algorithms share a majority of code.
      From a Kconfig interface perspective, it makes sense to present two
      distinct options. This requires #ifdefing out the SHA512
      implementation from sha512.c. The latter doesn't make any sense.
      It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
      seems to be the more polite way to handle the selection.
      Thus, automatically select SHA512 when SHA384 is enabled.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
    • Alexandru Gagniuc's avatar
      common: Remove unused CONFIG_FIT_SHAxxx selectors · eb5171dd
      Alexandru Gagniuc authored and Tom Rini's avatar Tom Rini committed
      Originally CONFIG_FIT_SHAxxx enabled specific SHA algos for and only
      for hash_calculate() in common/image-fit.c. However, since commit
       ("image: Drop IMAGE_ENABLE_SHAxxx"),
      the correct selector was changed to CONFIG_SHAxxx.
      The extra "_FIT_" variants are neither used, nor needed. Remove them.
      One defconfig disables FIT_SHA256, which is now changed to 'SHA256'.
      CMD_MVEBU_BUBT needs to select select SHA256 to avoid undefined
      references to "sha256_*()". bubt.c needs sha256, so this selection is
      correct. It is not clear why this problem did not manifest before.
      Note that SHA selection in SPL is broken for this exact reason. There
      is no corresponding SPL_SHAxxx. Fixing this is is beyond the scope of
      this change.
      Also note that we make CONFIG_FIT now imply SHA256, to make up for
      FIT_SHA256 previously being a default y option.
      Signed-off-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [trini: Add imply SHA256 to FIT]
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
  4. 07 Sep, 2021 10 commits
  5. 06 Sep, 2021 2 commits
  6. 04 Sep, 2021 10 commits
  7. 03 Sep, 2021 4 commits
  8. 01 Sep, 2021 1 commit
    • Matwey V. Kornilov's avatar
      btrfs: Use default subvolume as filesystem root · 94509b79
      Matwey V. Kornilov authored and Tom Rini's avatar Tom Rini committed
      BTRFS volume consists of a number of subvolumes which can be mounted separately
      from each other. The top-level subvolume always exists even if no subvolumes
      were created manually. A subvolume can be denoted as the default subvolume i.e.
      the subvolume which is mounted by default.
      The default "default subvolume" is the top-level one, but this is far from the
      common practices used in the wild. For instance, openSUSE provides an OS
      snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
      filesystem is located into a separate subvolume which is "default" but not
      "top-level". That means that the /boot/dtb/ directory is also located inside
      this default subvolume instead of top-level one.
      However, the existing btrfs u-boot driver always uses the top-level subvolume
      as the filesystem root. This behaviour 1) is inconsistent with
          mount /dev/sda1 /target
      command, which mount the default subvolume 2) leads to the issues when
      /boot/dtb cannot be found properly (see the reference).
      This patch uses the default subvolume as the filesystem root to overcome
      mentioned issues.
      Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
      Signed-off-by: default avatarMatwey V. Kornilov <matwey.kornilov@gmail.com>
      Fixes: f06bfcf5
       ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>