<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body style="width: 70ex;" vlink="#551A8B" text="#000000"
    link="#0B6CDA" bgcolor="#FFFFFF" alink="#EE0000">
    <br>
    <blockquote type="cite"
      cite="mid:8516574f-acea-8ed5-c574-3f8deb26f087@linux.vnet.ibm.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">Support for self save and self restore
            interface is advertised in the
            <br>
            device tree, along with the list of SPRs it supports for
            each.
            <br>
            <br>
            The Special Purpose Register identification is encoded in a
            2048 bitmask
            <br>
            structure, where each bit signifies the identification key
            of that SPR
            <br>
            which is consistent with that of the Linux kernel for that
            register.
            <br>
          </blockquote>
          <br>
          I assume this feature needs supported HCODE level. How do you
          determine whether HCODE supports
          <br>
          new feature or not?
          <br>
          <br>
          -Vasant </blockquote>
        As far as I know, Skiboot tries to make a stop API call with the
        highest version in mind,
        <br>
        if it fails it falls back to older version. The way we determine
        today if </blockquote>
      <br>
      In that case shouldn't we check this before advertising capability
      via DT to kernel?
      <br>
      <br>
      <br>
      -Vasant
      <br>
    </blockquote>
    Yes the idea that the whole point of advertising features in the DT<br>
    is to avoid the OS just throwing stuff at firmware and seeing what<br>
    works is sound. However, such a check does not currently exist and
    we got in touch with the firmware team and they said they'll let us
    know if something like this can be prioritized and supported.<br>
  </body>
</html>