[PATCH v2 0/3] lib: sbi: Fix Smrnmi resume init and optional platform callback

[Evgeny Voevodin]

Patch 3/3:

- About the mode variable: I don't think we need to keep any state just
  to indicate how Smrnmi trap handlers were initialized, if a simple
  check gives the same answer.

  sbi_boot_print_hart() (where the Smrnmi mode is indicated) is only
  reached in these cases:

  1. No Smrnmi detected (Smrnmi mode output is suppressed based on its
     absence)
  2. No platform handlers installed (Default)
  3. Platform handlers installed AND succeed (Platform)

  If a platform has handlers but the initialization didn't succeed
  (sbi_smrnmi_hart_init() returned non-zero) the hart gets hanged in
  init_coldboot() before any part of the banner is printed
  (sbi_init.c:299, the banner starts at sbi_init.c:440), so the Smrnmi
  mode line is never reached.

  So, I would still prefer to get rid of the Smrnmi mode variable in
  favor of a simple on the fly check.

- About the platform flag. Allowing the NULL callback is right, it fixes
  the panic on platforms with fixed or mtvec based vectors. My point is
  that NULL alone does not distinguish between platforms which
  intentionally didn't set the handlers and those which forgot to do
  this. Both proceed with csr_set(CSR_MNSTATUS, MNSTATUS_NMIE), so for
  the second one NMIs are enabled while the vendor vector register keeps
  its reset value, and the first RNMI jumps to an undefined address.
  This is broken in a way which might be hard to debug.

  A flag in sbi_platform which says "this platform has nothing to
  program" separates the two cases: no flag and no callback is then a
  platform error. This is what we agreed on in [1], options a) and c)
  together.

  Thanks,
  Evgeny

[1] https://lore.kernel.org/opensbi/CACpYXwCiciQzQo99=f=_wioYb3kHHTZkQm_UAi6FCXYpbJmeog@mail.gmail.com/