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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux