On 10/24/2022 5:41 PM, Joseph, Jithu wrote:
diff --git a/drivers/platform/x86/intel/ifs/core.c b/drivers/platform/x86/intel/ifs/core.c
index 27204e3d674d..5fb7f655c291 100644
--- a/drivers/platform/x86/intel/ifs/core.c
+++ b/drivers/platform/x86/intel/ifs/core.c
@@ -51,12 +51,8 @@ static int __init ifs_init(void)
ifs_device.misc.groups = ifs_get_groups();
if ((msrval & BIT(ifs_device.data.integrity_cap_bit)) &&
Is there a reason to store the integrity cap constant in the device.data global structure?
.data = {
.integrity_cap_bit = MSR_INTEGRITY_CAPS_PERIODIC_BIST_BIT,
},
This was originally added so that, when future additional tests are supported by the driver, support can be checked using the same if ((msrval & BIT(ifs_device.data.integrity_cap_bit)
Different tests would have different integrity_cap_bit assigned in the ifs_device[] array (today it is just a single element and not an array
Note that the current series doesn't introduce this
Sorry, I am still not able to follow.
Let's say you have an ifs_device[] array which has different integrity
capabilities, there would still need to be some logic in the init code
to differentiate between the resulting action that needs to be taken?
Currently, the init function only registers the device. Maybe some
example/code might be helpful to drive the point.
Also, are the future additional tests expected to be added soon? If not,
maybe we can defer this optimization until the need arrives.
Sohil
Jithu
