On 4/11/24 20:55, Elliot Berman wrote:
On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote:
In preparation for parsing the chip "feature code" (FC) and "product
code" (PC) (essentially the parameters that let us conclusively
characterize the sillicon we're running on, including various speed
bins), move the socinfo version defines to the public header and
include some more FC/PC defines.
Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
---
[...]
+ SOCINFO_FC_EXT_RESERVE,
+};
SOCINFO_FC_EXT_RESERVE was a convenient limit since we mapped
SOCINFO_FC_AA -> string "AA" via an array, and we've only needed the 8
feature codes so far.
We should remove the EXT_RESERVE and test for the Y0-YF (internal
feature code) values instead.
OK
+
+/* Internal feature codes */
+/* Valid values: 0 <= n <= 0xf */
+#define SOCINFO_FC_Yn(n) (0xf1 + n)
+#define SOCINFO_FC_INT_RESERVE SOCINFO_FC_Yn(0x10)
We probably should've named this SOCINFO_FC_INT_MAX. Reserve implies
it's reserved for some future use, but it's really the max value it
could be.
So, should SOCINFO_FC_Yn(0x10) also be considered valid, or is (0xf)
the last one?
+
+/* Product codes */
+#define SOCINFO_PC_UNKNOWN 0
+/* Valid values: 0 <= n <= 8, the rest is reserved */
+#define SOCINFO_PCn(n) (n + 1)
+#define SOCINFO_PC_RESERVE (BIT(31) - 1)
Similar comments here as the SOCINFO_FC_EXT_*. It's more like known
values are [0,8], but more values could come in future chipsets.
Ok, sounds good, I'll remove the comment then
Konrad
