<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>