Re: [PATCH 15/27] arm64/sve: Probe SVE capabilities and usable vector lengths

[Suzuki K Poulose <Suzuki.Poulose@arm.com>]

On 17/08/17 11:04, Dave Martin wrote:
> On Wed, Aug 16, 2017 at 06:48:01PM +0100, Suzuki K Poulose wrote:
>> On 09/08/17 13:05, Dave Martin wrote:
>>> [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Any idea what this is ^ ?  I don't know if this is caused by me or you,
> but I only seem to see it on subthreads you've replied to.
>

Dave,

Sorry about that, should have trimmed that. It looks like the mail server is unhappy
about email received via kvmarm list and I don't know why.

>>
>>> +void __init sve_setup(void)
>>> +{
>>> +       u64 zcr;
>>> +       unsigned int max_vl;
>>> +
>>> +       if (!system_supports_sve())
>>> +               return;
>>> +
>>> +       /*
>>> +        * The architecture mandates 128-bit vectors be supported, and
>>> +        * the code assumes elsewhere that sve_vq_map is non-empty:
>>> +        */
>>> +       BUG_ON(!test_bit(vq_to_bit(1), sve_vq_map));
>>> +
>>> +       sve_vq_map_finalised = true;
>>
>> We have something local in cpufeature.c, sys_caps_initialised. May be we could
>> reuse it here ? With or without that change, FWIW.
>
> I'll take a look at that.  Inventing that here seemed a little ugly, and
> this is all driven from the cpufreatures code anyway now which ensures a
> certain ordering.
>
> If I can reuse sys_caps_initialised for this, I will -- seems pointless
> to reinvent it.

Suzuki