Re: [PATCH v2 16/20] arm64: Handle shared capability entries

From: Suzuki K Poulose
Date: Thu Feb 08 2018 - 07:05:31 EST


On 08/02/18 12:04, Dave Martin wrote:
On Wed, Jan 31, 2018 at 06:28:03PM +0000, Suzuki K Poulose wrote:
Some capabilities have different criteria for detection and associated
actions based on the matching criteria, even though they all share the
same capability bit. So far we have used multiple entries with the same
capability bit to handle this. This is prone to errors, as the
cpu_enable is invoked for each entry, irrespective of whether the
detection rule applies to the CPU or not. And also this complicates
other helpers, e.g, __this_cpu_has_cap.

This patch adds a wrapper entry to cover all the possible variations
of a capability and ensures :
1) The capabilitiy is set when at least one of the entry detects
2) Action is only taken for the entries that detects.

This avoids explicit checks in the call backs. The only constraint
here is that, all the entries should have the same "type".

Cc: Dave Martin <dave.martin@xxxxxxx>
Cc: Will Deacon <will.deacon@xxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
---

[...]

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c

[...]

@@ -1275,7 +1274,7 @@ static bool __verify_local_cpu_caps(const struct arm64_cpu_capabilities *caps_li
if (!(caps->type & scope_mask))
continue;
- cpu_has_cap = __this_cpu_has_cap(caps_list, caps->capability);
+ cpu_has_cap = caps->matches(caps, SCOPE_LOCAL_CPU);

One other minor thing: the original caps_list argument seems no longer
to be needed in this function after this change.

Can we rename the caps_list argument to "caps" and remove the local
variable of the same name?

Sure, will do.

Suzuki