lkml.org 
[lkml]   [2018]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 08/16] arm64: capabilities: Group handling of features and errata
From
Date
On 26/01/18 11:47, Dave Martin wrote:
> On Tue, Jan 23, 2018 at 12:28:01PM +0000, Suzuki K Poulose wrote:
>> So far we have had separate routes for triggering errata and feature
>
> "triggering errata" ? ;)
>

:-). Should have been "triggering errata and feature capability *checks*.

> Maybe "[...] for determining whether to activate errata workarounds and
> whether to enable feature capabilities."
>


>> capabilities. Also, we never allowed "features" based on local CPU
>> and "errata" based on System wide safe registers. This patch
>> groups the handling of errata and features and also allows them
>> to have all the possible scopes.
>>
>> So, we now run through the arm64_features and arm64_errata:
>
> when?

with this patch.

> What about late cpus?
>

We don't detect any new capabilities on them. They continue to get
verified against the enabled capabilities.

>> 1) with SCOPE_LOCAL_CPU filter on each boot time enabeld CPUs,
>> via update_cpu_local_capabilities().
>
> "each [...] enabeld CPUs" -> "each [...] enabled CPU"
>
> Also, changing "boot time" -> "boot-time" helps avoid this being misread
> as "on each boot", which could be taken to mean "each time a CPU comes
> online". I'm guessing that's not the intended meaning here.

OK


>> /*
>> - * The CPU Errata work arounds are detected and applied at boot time
>> - * and the related information is freed soon after. If the new CPU requires
>> - * an errata not detected at boot, fail this CPU.
>> + * Check for all capablities within the scope of local CPU.
>> + * This is run on all boot time activated CPUs.
>> */
>> -static void verify_local_cpu_errata_workarounds(void)
>> +static void update_cpu_local_capabilities(void)
>
> [Gaah, stupid git diff making function insertion look like function
> modification. Sometimes --patience does a better job, but there seems
> no foolproof solution... If you do a respin, it might be worth trying
> it.]

Will try, thanks for the suggestion. I didn't know about that :-)

>> -static void __init setup_feature_capabilities(void)
>> +static void __init setup_system_capabilities(void)
>> {
>> - update_cpu_capabilities(arm64_features,
>> - ARM64_CPUCAP_TYPE_ALL, "detected feature:");
>> - enable_cpu_capabilities(arm64_features, ARM64_CPUCAP_TYPE_ALL);
>> + /*
>> + * We have finalised the system wide safe feature registers,
>> + * finalise the capabilities that depend on it.
>> + */
>> + update_system_capabilities();
>> + /* Enable all the available capabilities */
>> + enable_cpu_capabilities(ARM64_CPUCAP_TYPE_ALL);
>
> So setup_system_capabilities() enables _non_ system-wide capabilities/
> errata workarounds too?

> Maybe this function should just have a different name, like
> "setup_boot_capabilities" or similar?

The problem with setup_boot_capabilities() is that it could conflict with
"coming soon" setup_boot_cpu_capabilities(). May be,

setup_boot_time_system_capabilities().


>
> }
>>
>> DEFINE_STATIC_KEY_FALSE(arm64_const_caps_ready);
>> @@ -1422,9 +1435,7 @@ void __init setup_cpu_features(void)
>> u32 cwg;
>> int cls;
>>
>> - /* Set the CPU feature capabilies */
>> - setup_feature_capabilities();
>> - enable_errata_workarounds();
>> + setup_system_capabilities();
>> mark_const_caps_ready();
>> setup_elf_hwcaps(arm64_elf_hwcaps);
>
> I wonder whether we could unify the elf hwcaps handling too.

I was thinking about it today. The only catch is how do we know
if we have "the capability", as it is spread across multiple bitmasks.
(HWCAP, COMPAT_HWCAP, COMPAT_HWCAP2).

Suzuki

\
 
 \ /
  Last update: 2018-01-26 13:31    [W:0.053 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site