* Re: [PATCH v8 03/15] wlcore: simplify/fix/optimize reg_ch_conf_pending operations
From: Kalle Valo @ 2019-04-25 17:12 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li , Christopherson Sean J, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless, Fenghua Yu
In-Reply-To: <1556134382-58814-4-git-send-email-fenghua.yu@intel.com>
Fenghua Yu <fenghua.yu@intel.com> wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> Bitmaps are defined on unsigned longs, so the usage of u32[2] in the
> wlcore driver is incorrect. As noted by Peter Zijlstra, casting arrays
> to a bitmap is incorrect for big-endian architectures.
>
> When looking at it I observed that:
>
> - operations on reg_ch_conf_pending is always under the wl_lock mutex,
> so set_bit is overkill
>
> - the only case where reg_ch_conf_pending is accessed a u32 at a time is
> unnecessary too.
>
> This patch cleans up everything in this area, and changes tmp_ch_bitmap
> to have the proper alignment.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Patch applied to wireless-drivers-next.git, thanks.
147b502bda33 wlcore: simplify/fix/optimize reg_ch_conf_pending operations
--
https://patchwork.kernel.org/patch/10915635/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
From: Mark Brown @ 2019-04-25 18:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Bjorn Helgaas,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Johannes Berg, David S. Miller, linux-pm, linux-pci,
linux-arm-kernel, intel-gfx, dri-devel, linux-wireless, netdev
In-Reply-To: <7adf9035ae06ecc6c7e46b51cb677f0a8f61d19a.1555938376.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
This is massively CCed covering a large range of subsystems and is patch
25 of a 79 patch series so I've no context for what's going on here or
why...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 19:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425054511.GA40105@gmail.com>
On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > enumerates a model specific feature. Currently bit 5 enumerates split
> > lock detection. When bit 5 is 1, split lock detection is supported.
> > When the bit is 0, split lock detection is not supported.
> >
> > Please check the latest Intel 64 and IA-32 Architectures Software
> > Developer's Manual for more detailed information on the MSR and the
> > split lock detection bit.
> >
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > ---
> > arch/x86/include/asm/msr-index.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > index ca5bc0eacb95..f65ef6f783d2 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -59,6 +59,9 @@
> > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> >
> > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
>
> Please don't put comments into definitions.
I'll remove the comment and change definitions of the MSR and the split lock
detection bit as following:
+#define MSR_IA32_CORE_CAPABILITY 0x000000cf
+#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
+#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
Are these right changes?
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Ingo Molnar @ 2019-04-25 19:47 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425190148.GA64477@romley-ivt3.sc.intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> >
> > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> >
> > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > When the bit is 0, split lock detection is not supported.
> > >
> > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > Developer's Manual for more detailed information on the MSR and the
> > > split lock detection bit.
> > >
> > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > ---
> > > arch/x86/include/asm/msr-index.h | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > --- a/arch/x86/include/asm/msr-index.h
> > > +++ b/arch/x86/include/asm/msr-index.h
> > > @@ -59,6 +59,9 @@
> > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > >
> > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> >
> > Please don't put comments into definitions.
>
> I'll remove the comment and change definitions of the MSR and the split lock
> detection bit as following:
>
> +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
>
> Are these right changes?
I suspect it could be shortened to CORE_CAP as you (partly) did it
originally.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v8 09/15] x86/split_lock: Define MSR TEST_CTL register
From: Fenghua Yu @ 2019-04-25 19:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425062126.GC40105@gmail.com>
On Thu, Apr 25, 2019 at 08:21:26AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > Setting bit 29 in MSR TEST_CTL (0x33) enables split lock detection and
> > clearing the bit disables split lock detection.
> >
> > Define the MSR and the bit. The definitions will be used in enabling or
> > disabling split lock detection.
> >
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > ---
> > arch/x86/include/asm/msr-index.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > index f65ef6f783d2..296eeb761ab6 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -39,6 +39,10 @@
> >
> > /* Intel MSRs. Some also available on other CPUs */
> >
> > +#define MSR_TEST_CTL 0x00000033
> > +#define TEST_CTL_SPLIT_LOCK_DETECT_SHIFT 29
> > +#define TEST_CTL_SPLIT_LOCK_DETECT BIT(29)
>
> Three problems:
>
> - Is MSR_TEST_CTL is not really a canonical MSR name... A quick look at
> msr-index reveals the prevailing nomenclature:
>
> dagon:~/tip> git grep -h 'define MSR' arch/x86/include/asm/msr-index.h | cut -d_ -f1-2 | sort -n | uniq -c | sort -n | tail -10
> 8 #define MSR_K8
> 8 #define MSR_MTRRfix4K
> 12 #define MSR_CORE
> 13 #define MSR_IDT
> 14 #define MSR_K7
> 16 #define MSR_PKG
> 19 #define MSR_F15H
> 33 #define MSR_AMD64
> 83 #define MSR_P4
> 163 #define MSR_IA32
>
> I.e. this shouldn't this be something like MSR_IA32_TEST_CTL - or this
> the name the Intel SDM uses? (I haven't checked.)
TEST_CTL is the MSR's exact name shown in Table 2-14 in the latest SDM.
https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
So can I still use MSR_TEST_CTL here?
>
> - The canonical way to define MSR capabilities is to use the MSR's name
> as a prefix. I.e.:
>
> MSR_TEST_CTL
> MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT
> MSR_TEST_CTL_SPLIT_LOCK_DETECT
> etc.
>
> Instead of the random mixture of MSR_ prefixed and non-prefixed
> MSR_TEST_CTL, TEST_CTL_SPLIT_LOCK_DETECT_SHIFT and
> TEST_CTL_SPLIT_LOCK_DETECT names.
>
> - Finally, this is not how we define bits - the _SHIFT postfix is actively
> confusing as we usually denote _SHIFT values with something that is
> used in a bit-shift operation, which this isn't. Instead the proper
> scheme is to postfix the bit number with _BIT and the mask with _MASK,
> i.e. something like:
>
> #define MSR_TEST_CTL 0x00000033
> #define MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT 29
> #define MSR_TEST_CTL_SPLIT_LOCK_DETECT BIT(MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT)
>
> Note how this cleans up actual usage:
>
> + msr_set_bit(MSR_TEST_CTL, TEST_CTL_SPLIT_LOCK_DETECT_SHIFT);
> + this_cpu_or(msr_test_ctl_cache, TEST_CTL_SPLIT_LOCK_DETECT);
>
> - msr_set_bit(MSR_TEST_CTL, MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT);
> - this_cpu_or(msr_test_ctl_cache, MSR_TEST_CTL_SPLIT_LOCK_DETECT);
>
> Frankly, this kind of disorganized code in a v8 submission is *really*
> disappointing, it's not like it's hard to look up these patterns and
> practices in existing code...
OK. Will change the bit and mask definitions.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 19:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425194714.GA58719@gmail.com>
On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > >
> > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > >
> > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > When the bit is 0, split lock detection is not supported.
> > > >
> > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > Developer's Manual for more detailed information on the MSR and the
> > > > split lock detection bit.
> > > >
> > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > ---
> > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > --- a/arch/x86/include/asm/msr-index.h
> > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > @@ -59,6 +59,9 @@
> > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > >
> > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > >
> > > Please don't put comments into definitions.
> >
> > I'll remove the comment and change definitions of the MSR and the split lock
> > detection bit as following:
> >
> > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> >
> > Are these right changes?
>
> I suspect it could be shortened to CORE_CAP as you (partly) did it
> originally.
IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
So can I define the MSR and the bits as follows?
+#define MSR_IA32_CORE_CAP 0x000000cf
+#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
+#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Ingo Molnar @ 2019-04-25 20:08 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425195154.GC64477@romley-ivt3.sc.intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> >
> > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> >
> > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > >
> > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > When the bit is 0, split lock detection is not supported.
> > > > >
> > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > split lock detection bit.
> > > > >
> > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > ---
> > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > @@ -59,6 +59,9 @@
> > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > >
> > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > >
> > > > Please don't put comments into definitions.
> > >
> > > I'll remove the comment and change definitions of the MSR and the split lock
> > > detection bit as following:
> > >
> > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > >
> > > Are these right changes?
> >
> > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > originally.
>
> IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
>
> So can I define the MSR and the bits as follows?
>
> +#define MSR_IA32_CORE_CAP 0x000000cf
> +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
Yeah, I suppose that looks OK.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 20:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425200830.GD58719@gmail.com>
On Thu, Apr 25, 2019 at 10:08:30PM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> > >
> > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > >
> > > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > > >
> > > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > > >
> > > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > > When the bit is 0, split lock detection is not supported.
> > > > > >
> > > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > > split lock detection bit.
> > > > > >
> > > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > > ---
> > > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > > @@ -59,6 +59,9 @@
> > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > > >
> > > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > > >
> > > > > Please don't put comments into definitions.
> > > >
> > > > I'll remove the comment and change definitions of the MSR and the split lock
> > > > detection bit as following:
> > > >
> > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > > >
> > > > Are these right changes?
> > >
> > > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > > originally.
> >
> > IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> > https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
> >
> > So can I define the MSR and the bits as follows?
> >
> > +#define MSR_IA32_CORE_CAP 0x000000cf
> > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
>
> Yeah, I suppose that looks OK.
Should I also change the feature definition 'X86_FEATURE_CORE_CAPABILITY' to
'X86_FEATURE_CORE_CAP' in cpufeatures.h in patch #0006 to match the
MSR definition here? Or should I still keep the current feature definition?
Thanks.
-Fenghua
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules for South Korea
From: b.K.il.h.u+tigbuh @ 2019-04-25 20:37 UTC (permalink / raw)
To: Peter Oh
Cc: linux-wireless@vger.kernel.org,
wireless-regdb@lists.infradead.org, Seth Forshee
In-Reply-To: <b7af6387-a8bf-dfa0-b347-e58133d7298d@bowerswilkins.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
Thank you for the information.
I could also successfully download 2016-125*2016.11.30*.hwp from here:
https://www.rra.go.kr/ko/reference/lawList_view.do?lw_seq=55&lw_type=3&searchCon=&lw_select=ALL&lw_model=&searchTxt=
And then convert it using this online tool:
https://appzend.herokuapp.com/hwpviewer/
It resulted in an HTML where copy&pasting also works (attached).
Translation of sections of interest are straight forward using an
online translator, like:
https://www.bing.com/translator
I haven't read through the document thoroughly yet, but I found
similar data to the table attached above below the section titled:
"주파수대역, 전력밀도 등"
Note that a link to the 2016-124 document is specified as reference in
the above code (conversion also attached), not to 2016-125. Should we
update the link? Although some of the numbers seem to match, the
documents differ in structure and -125 seems to handle more bands.
I do recommend that someone gives a second look into the numbers, as
some of the frequency ranges seem to have been extended as well. For
example, both this table and the document mentions:
2400-2483.5 instead of 2402-2482,
5150-5250 instead of 5170-5250,
5470-5725 instead of 5490-5710 and
5725-5850 instead of 5735-5835.
On Wed, Apr 24, 2019 at 7:33 PM Peter Oh <peter.oh@bowerswilkins.com> wrote:
>
>
>
> On 04/23/2019 01:54 PM, b.K.il.h.u+tigbuh@gmail.com wrote:
> > Could you please convert the document in question to a more open
> > format so we could try machine translation on it? ODT, HTML, docx and
> > PDF would probably work as long as copy & pasting is enabled.
> Please find attachment for converted one to PDF and also summary of
> power density.
> The spec for 2.4GHz and 5GHz devices are addressed in page 18, 19, 24
> and 25.
> (Page 26 is for non-DSSS modulation).
>
> Thanks,
> Peter
>
>
[-- Attachment #2: 27._2016-124__2016.11.30.hwp.zip --]
[-- Type: application/zip, Size: 16808 bytes --]
[-- Attachment #3: 2016-125__2016.11.30.hwp.zip --]
[-- Type: application/zip, Size: 48682 bytes --]
^ permalink raw reply
* Re: [PATCH] mmc: dw_mmc: Disable SDIO interrupts while suspended to fix suspend/resume
From: Doug Anderson @ 2019-04-25 21:24 UTC (permalink / raw)
To: Emil Renner Berthing
Cc: Jaehoon Chung, Ulf Hansson, Shawn Lin, Heiko Stuebner,
Linux MMC List, Brian Norris, linux-wireless, stable,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
Matthias Kaehlcke, Ryan Case, Kalle Valo
In-Reply-To: <CANBLGcwmNowj9GSmE3bbo1t1o6EF8q-RiJftfdOQnJB9_8aSKg@mail.gmail.com>
Hi,
On Wed, Apr 24, 2019 at 1:19 AM Emil Renner Berthing
<emil.renner.berthing@gmail.com> wrote:
>
> Hi Douglas,
>
> Unfortunately this seems to beak resume on my rk3399-gru-kevin. I have
> a semi-complicated setup with my rootfs as a btrfs on dmcrypt on
> mmcblk0 which is the dw_mmc, so I'm guessing something goes wrong when
> waking up the dm_mmc which probably wasn't suspended before this
> patch. It's not 100% consistent though. Sometimes I see it resume the
> first time I try suspending, but then 2nd time I suspend it won't come
> back.
Thanks for testing!
Can you give me more details about your kernel version? Any local
patches? What config are you using?
I tried booting up my rk3388-gru-kevin on the Chrome OS 4.19 kernel (I
know, not quite fully upstream, but linuxnext just crashed upon boot
for me when I tried it). I have this patch in place and I booted from
SD card. I ran a Chrome OS tool which will test 20 cycles of
suspend/resume (uses the RTC to schedule a wakeup):
suspend_stress_test -c20 --suspend_min=15 --suspend_max=20
...and I didn't see failures.
...so I'm pretty baffled. On rk3399-gru-kevin you should have no SDIO
devices unless you've managed to cram an SDIO card into your micro SD
slot. Specifically WiFi is connected via PCIE.
As I wrote Shawn, I'm pretty sure my patch is a effectively a no-op in
these cases. "client_sdio_enb" should always be 0 and thus runtime
suspend and resume should just be:
spin_lock_irqsave(&host->irq_lock, irqflags);
int_mask = mci_readl(host, INTMASK);
mci_writel(host, INTMASK, int_mask);
spin_unlock_irqrestore(&host->irq_lock, irqflags);
...other than changing the timing slightly that shouldn't do anything at all.
My first guess is that this patch is your (un)lucky shirt, as in
"every time I wear my lucky shirt I win at slots in Las Vegas". Since
the problem you're seeing doesn't happen every time I'm going to guess
that you got lucky in that it seemed to go away when you reverted my
patch.
> Let me know if I can do something to help debug this.
Assuming the failure and this patch aren't just correlated by luck...
Logs would be a start. If you don't have serial console then
hopefully you've got console-ramoops working? Then if it's wedged you
can do the warmest reset you can (Alt-topRowVolUp-R) and hopefully the
ramoops will give you some logs.
Presumably you could also add some logs to double-check that all my
assertions are true. That is:
1. host->client_sdio_enb should always be false in __dw_mci_enable_sdio_irq()
2. In __dw_mci_enable_sdio_irq() confirm that the int_mask we are
writing is the same as the one we're reading. AKA the "if (enb) ...
else ..." makes no change to the value of int_mask.
Assuming my assertions are correct then pretty much everything is
_supposed_ to be a no-op on your system, so you can start gutting
things one at a time and see when the problem goes away:
a) Delete the call from suspend. Does it fix it?
b) Delete the call from resume. Does it fix it?
c) Delete parts of __dw_mci_enable_sdio_irq(). Get rid of the
mci_wirtel(). Does it fix it? What about if you get rid of the read
and the write and just have the spinlock?
===
If I can help with real-time debugging let me know. I'm in California
time zone and can be found as dianders in the #linux-rockchip channel
on freenode.
-Doug
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Johannes Berg @ 2019-04-25 21:25 UTC (permalink / raw)
To: Arnd Bergmann, Al Viro
Cc: Mauro Carvalho Chehab, Linux FS-devel Mailing List,
y2038 Mailman List, Linux Kernel Mailing List, Jason Gunthorpe,
Daniel Vetter, Greg Kroah-Hartman, David Sterba, Darren Hart,
Jonathan Cameron, Bjorn Andersson, driverdevel, qat-linux,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
Linux Media Mailing List, dri-devel, linaro-mm-sig, amd-gfx,
open list:HID CORE LAYER, linux-iio, linux-rdma, linux-nvdimm,
linux-nvme, linux-pci, Platform Driver, linux-remoteproc,
sparclinux, linux-scsi, USB list, linux-btrfs, ceph-devel,
linux-wireless, Networking, Sean Young
In-Reply-To: <CAK8P3a2HmiYQJ2FV2FgLiFsD8M9UKteC9Jetx7ja06PQVZWYfA@mail.gmail.com>
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> >
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument. IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
>
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this
Actually, you can't even do that because the struct might sit at the end
of a page and then you'd erroneously fault in this case.
We had this a while ago with struct ifreq, see commit 98406133dd and its
parents.
johannes
^ permalink raw reply
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: b.K.il.h.u+tigbuh @ 2019-04-25 22:00 UTC (permalink / raw)
To: seth.forshee; +Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <20190408124829.GD15126@ubuntu-xps13>
This seems to be the page for the previous standard:
https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
And the following should be the new standard, but I don't know where
to obtain it:
https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
The description fields here do note the range of 57-66GHz, though:
https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
https://webstore.arib.or.jp/en/products/detail.php?product_id=288
Similar mentions in the news (search for T117):
https://www.arib.or.jp/image/osirase/news/1044.pdf
https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
Testing procedure is described here, not sure if it's considered useful:
file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
On Mon, Apr 8, 2019 at 2:48 PM seth.forshee <seth.forshee@canonical.com> wrote:
>
> On Mon, Apr 01, 2019 at 06:07:44PM +0800, junping.xu@jaguarwave.com wrote:
> > Hi Forsheee,
> > The 60GHz band defined for Japan was between 59-66GHz, but is has been Updated to support 57-66Ghz about 2 years ago。
> > However, the latest wireless-regdb still containning the original regulatory information as below. Please help to check the infomation
> > and update the regulatory.bin.
> >
> > db.txt:
> > ......
> > country JP: DFS-JP
> > (2402 - 2482 @ 40), (20)
> > (2474 - 2494 @ 20), (20), NO-OFDM
> > (4910 - 4990 @ 40), (23)
> > (5030 - 5090 @ 40), (23)
> > (5170 - 5250 @ 80), (20), AUTO-BW
> > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > (5490 - 5710 @ 160), (23), DFS
> > # 60 GHz band channels 2-4 at 10mW,
> > # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
>
> The only change which is required to change:
>
> > (59000 - 66000 @ 2160), (10 mW)
>
> to:
>
> (57000 - 66000 @ 2160), (10 mW)
>
> Is that right? Can you provide a link to the documentation which
> supports this change? The current link above this rule appears to be
> broken.
>
> Thanks,
> Seth
>
> _______________________________________________
> wireless-regdb mailing list
> wireless-regdb@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: b.K.il.h.u+tigbuh @ 2019-04-25 22:01 UTC (permalink / raw)
To: seth.forshee; +Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <CAPuHQ=EvWzXtxk0fLOT6PyeYkcNOOXmw0ck-yT-JsqhhDmu2gA@mail.gmail.com>
P.S.: last link should have been
https://www.tuv.com/content-media-files/japan/pdfs/1190-telecom-and-radio-for-japan/1190-letter/60ghz2_1_19_4_2_1.pdf
On Fri, Apr 26, 2019 at 12:00 AM <b.K.il.h.u+tigbuh@gmail.com> wrote:
>
> This seems to be the page for the previous standard:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
>
> And the following should be the new standard, but I don't know where
> to obtain it:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
>
> The description fields here do note the range of 57-66GHz, though:
> https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
> https://webstore.arib.or.jp/en/products/detail.php?product_id=288
>
> Similar mentions in the news (search for T117):
> https://www.arib.or.jp/image/osirase/news/1044.pdf
> https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
>
> Testing procedure is described here, not sure if it's considered useful:
> file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
>
> On Mon, Apr 8, 2019 at 2:48 PM seth.forshee <seth.forshee@canonical.com> wrote:
> >
> > On Mon, Apr 01, 2019 at 06:07:44PM +0800, junping.xu@jaguarwave.com wrote:
> > > Hi Forsheee,
> > > The 60GHz band defined for Japan was between 59-66GHz, but is has been Updated to support 57-66Ghz about 2 years ago。
> > > However, the latest wireless-regdb still containning the original regulatory information as below. Please help to check the infomation
> > > and update the regulatory.bin.
> > >
> > > db.txt:
> > > ......
> > > country JP: DFS-JP
> > > (2402 - 2482 @ 40), (20)
> > > (2474 - 2494 @ 20), (20), NO-OFDM
> > > (4910 - 4990 @ 40), (23)
> > > (5030 - 5090 @ 40), (23)
> > > (5170 - 5250 @ 80), (20), AUTO-BW
> > > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > > (5490 - 5710 @ 160), (23), DFS
> > > # 60 GHz band channels 2-4 at 10mW,
> > > # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
> >
> > The only change which is required to change:
> >
> > > (59000 - 66000 @ 2160), (10 mW)
> >
> > to:
> >
> > (57000 - 66000 @ 2160), (10 mW)
> >
> > Is that right? Can you provide a link to the documentation which
> > supports this change? The current link above this rule appears to be
> > broken.
> >
> > Thanks,
> > Seth
> >
> > _______________________________________________
> > wireless-regdb mailing list
> > wireless-regdb@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules for South Korea
From: Peter Oh @ 2019-04-25 22:14 UTC (permalink / raw)
To: b.K.il.h.u+tigbuh@gmail.com
Cc: linux-wireless@vger.kernel.org,
wireless-regdb@lists.infradead.org, Seth Forshee
In-Reply-To: <CAPuHQ=EMmq7M7HHAO8iMrOgsgn9dAg=siUWXQMc0sA_8t_kBAg@mail.gmail.com>
On 04/25/2019 01:37 PM, b.K.il.h.u+tigbuh@gmail.com wrote:
> Note that a link to the 2016-124 document is specified as reference in
> the above code (conversion also attached), not to 2016-125. Should we
> update the link? Although some of the numbers seem to match, the
> documents differ in structure and -125 seems to handle more bands.
I don't know where you downloaded 2016-124, but there is no link to
2016-124 one RAA website.
https://www.rra.go.kr/ko/reference/lawList_view.do?lw_seq=55&lw_type=3&searchCon=&lw_select=ALL&lw_model=&searchTxt=
Even though 2016-124 exist, we should refer 2016-125 since it's later
version than -124.
Thanks,
Peter
^ permalink raw reply
* Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
From: linux-wireless @ 2019-04-25 22:04 UTC (permalink / raw)
To: linux-wireless
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
^ permalink raw reply
* [PATCH v3] brcmfmac: send mailbox interrupt twice for specific hardware device
From: Wright Feng @ 2019-04-26 3:12 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, kvalo@codeaurora.org, Chi-Hsien Lin
Cc: Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
For PCIE wireless device with core revision less than 14, device may miss
PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending
mail box interrupt twice as a hardware workaround.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
---
v2: add comment and check for PCIE core revision
v3: fix compile error
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index fd3968f..d7d3e93 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -675,6 +675,7 @@ static int
brcmf_pcie_send_mb_data(struct brcmf_pciedev_info *devinfo, u32 htod_mb_data)
{
struct brcmf_pcie_shared_info *shared;
+ struct brcmf_core *core;
u32 addr;
u32 cur_htod_mb_data;
u32 i;
@@ -698,7 +699,11 @@ brcmf_pcie_send_mb_data(struct brcmf_pciedev_info *devinfo, u32 htod_mb_data)
brcmf_pcie_write_tcm32(devinfo, addr, htod_mb_data);
pci_write_config_dword(devinfo->pdev, BRCMF_PCIE_REG_SBMBX, 1);
- pci_write_config_dword(devinfo->pdev, BRCMF_PCIE_REG_SBMBX, 1);
+
+ /* Send mailbox interrupt twice as a hardware workaround */
+ core = brcmf_chip_get_core(devinfo->ci, BCMA_CORE_PCIE2);
+ if (core->rev <= 13)
+ pci_write_config_dword(devinfo->pdev, BRCMF_PCIE_REG_SBMBX, 1);
return 0;
}
--
2.1.0
^ permalink raw reply related
* [PATCH] mt7615: add TX/RX antenna pattern capabilities
From: Ryder Lee @ 2019-04-26 3:36 UTC (permalink / raw)
To: Lorenzo Bianconi, Felix Fietkau
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, linux-wireless,
linux-mediatek, linux-kernel, Ryder Lee
Announce antenna pattern cap to adapt PHY and baseband settings.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 3ab3ff553ef2..122f7a565540 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -190,6 +190,8 @@ int mt7615_register_device(struct mt7615_dev *dev)
IEEE80211_VHT_CAP_SHORT_GI_160 |
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454 |
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK |
+ IEEE80211_VHT_CAP_RX_ANTENNA_PATTERN |
+ IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN |
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
dev->mt76.chainmask = 0x404;
dev->mt76.antenna_mask = 0xf;
--
2.18.0
^ permalink raw reply related
* Re: [wireless-drivers-next:master 28/45] drivers/net/wireless/rsi/rsi_91x_usb.c:229:27: sparse: restricted __le32 degrades to integer
From: Kalle Valo @ 2019-04-26 3:38 UTC (permalink / raw)
To: Siva Rebbagondla; +Cc: kbuild test robot, kbuild-all, linux-wireless
In-Reply-To: <CANGSkXQUwyAsQxKFrJSeycDJ-X5SUnoXroJt0a2tjg2btSyZvQ@mail.gmail.com>
+ linux-wireless
Siva Rebbagondla <siva8118@gmail.com> writes:
> Hi Kalle,
>
> On Fri, Apr 26, 2019 at 1:06 AM kbuild test robot <lkp@intel.com> wrote:
>>
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
>> head: 147b502bda338f4f2dff19faaa5829b691305ea5
>> commit: 0a60014b76f512f18e48cfb4efc71e07c6791996 [28/45] rsi: miscallaneous changes for 9116 and common
>> reproduce:
>> # apt-get install sparse
>> git checkout 0a60014b76f512f18e48cfb4efc71e07c6791996
>> make ARCH=x86_64 allmodconfig
>> make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>
>> >> drivers/net/wireless/rsi/rsi_91x_usb.c:229:27: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:230:27: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:231:27: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:232:27: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:238:36: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:239:35: sparse: restricted __le32 degrades to integer
>> drivers/net/wireless/rsi/rsi_91x_usb.c:354:28: sparse: expression using sizeof(void)
>> drivers/net/wireless/rsi/rsi_91x_usb.c:401:28: sparse: expression using sizeof(void)
>>
>> vim +229 drivers/net/wireless/rsi/rsi_91x_usb.c
>>
>> 203
>> 204 /**
>> 205 * rsi_usb_reg_write() - This function writes the given data into the given
>> 206 * register address.
>> 207 * @usbdev: Pointer to the usb_device structure.
>> 208 * @reg: Address of the register.
>> 209 * @value: Value to write.
>> 210 * @len: Length of data to be written.
>> 211 *
>> 212 * Return: status: 0 on success, a negative error code on failure.
>> 213 */
>> 214 static int rsi_usb_reg_write(struct usb_device *usbdev,
>> 215 u32 reg,
>> 216 u32 value,
>> 217 u16 len)
>> 218 {
>> 219 u8 *usb_reg_buf;
>> 220 int status = -ENOMEM;
>> 221
>> 222 if (len > RSI_USB_CTRL_BUF_SIZE)
>> 223 return -EINVAL;
>> 224
>> 225 usb_reg_buf = kmalloc(RSI_USB_CTRL_BUF_SIZE, GFP_KERNEL);
>> 226 if (!usb_reg_buf)
>> 227 return status;
>> 228
>> > 229 usb_reg_buf[0] = (cpu_to_le32(value) & 0x00ff);
>> 230 usb_reg_buf[1] = (cpu_to_le32(value) & 0xff00) >> 8;
>> 231 usb_reg_buf[2] = (cpu_to_le32(value) & 0x00ff0000) >> 16;
>> 232 usb_reg_buf[3] = (cpu_to_le32(value) & 0xff000000) >> 24;
>> 233
>> 234 status = usb_control_msg(usbdev,
>> 235 usb_sndctrlpipe(usbdev, 0),
>> 236 USB_VENDOR_REGISTER_WRITE,
>> 237 RSI_USB_REQ_OUT,
>> 238 ((cpu_to_le32(reg) & 0xffff0000) >> 16),
>> 239 (cpu_to_le32(reg) & 0xffff),
>> 240 (void *)usb_reg_buf,
>> 241 len,
>> 242 USB_CTRL_SET_TIMEOUT);
>> 243 if (status < 0) {
>> 244 rsi_dbg(ERR_ZONE,
>> 245 "%s: Reg write failed with error code :%d\n",
>> 246 __func__, status);
>> 247 }
>> 248 kfree(usb_reg_buf);
>> 249
>> 250 return status;
>> 251 }
>> 252
>>
>> ---
>> 0-DAY kernel test infrastructure Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
> Some where went wrong. I fixed this one. I will resend you the patches
> with changes.
Your patches are now applied and cannot be changed, so no point of
resending them anymore. You need to send followup patches which fix the
issues and apply to wireless-drivers-next.
And remember to use Fixes tag so that we know which commit patch fixes.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] brcmfmac: set txflow request id from 1 to pktids array size
From: Wright Feng @ 2019-04-26 3:41 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, kvalo@codeaurora.org, Chi-Hsien Lin
Cc: Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
Some PCIE firmwares drop txstatus if pktid is 0 and make packet held in
host side and never be released. If that packet type is 802.1x, the
pend_8021x_cnt value will be always greater than 0 and show "Timed out
waiting for no pending 802.1x packets" error message when sending key to
dongle every time.
To be compatible with all firmwares, host should set txflow request id
from 1 instead of from 0.
Signed-off-by: Wright Feng <wright.feng@cypress.com>
---
v2: change for not wasting the first entry
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index d3780ea..9d1f9ff 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -375,7 +375,7 @@ brcmf_msgbuf_get_pktid(struct device *dev, struct brcmf_msgbuf_pktids *pktids,
struct brcmf_msgbuf_pktid *pktid;
struct sk_buff *skb;
- if (idx >= pktids->array_size) {
+ if (idx < 0 || idx >= pktids->array_size) {
brcmf_err("Invalid packet id %d (max %d)\n", idx,
pktids->array_size);
return NULL;
@@ -747,7 +747,7 @@ static void brcmf_msgbuf_txflow(struct brcmf_msgbuf *msgbuf, u16 flowid)
tx_msghdr = (struct msgbuf_tx_msghdr *)ret_ptr;
tx_msghdr->msg.msgtype = MSGBUF_TYPE_TX_POST;
- tx_msghdr->msg.request_id = cpu_to_le32(pktid);
+ tx_msghdr->msg.request_id = cpu_to_le32(pktid + 1);
tx_msghdr->msg.ifidx = brcmf_flowring_ifidx_get(flow, flowid);
tx_msghdr->flags = BRCMF_MSGBUF_PKT_FLAGS_FRAME_802_3;
tx_msghdr->flags |= (skb->priority & 0x07) <<
@@ -884,7 +884,7 @@ brcmf_msgbuf_process_txstatus(struct brcmf_msgbuf *msgbuf, void *buf)
u16 flowid;
tx_status = (struct msgbuf_tx_status *)buf;
- idx = le32_to_cpu(tx_status->msg.request_id);
+ idx = le32_to_cpu(tx_status->msg.request_id) - 1;
flowid = le16_to_cpu(tx_status->compl_hdr.flow_ring_id);
flowid -= BRCMF_H2D_MSGRING_FLOWRING_IDSTART;
skb = brcmf_msgbuf_get_pktid(msgbuf->drvr->bus_if->dev,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] mt7615: add TX/RX antenna pattern capabilities
From: Kalle Valo @ 2019-04-26 4:22 UTC (permalink / raw)
To: Ryder Lee
Cc: Lorenzo Bianconi, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung,
Sean Wang, linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <4f0780666982b3e935f46abcfe434bc68c232fb0.1556249572.git.ryder.lee@mediatek.com>
Ryder Lee <ryder.lee@mediatek.com> writes:
> Announce antenna pattern cap to adapt PHY and baseband settings.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 2 ++
> 1 file changed, 2 insertions(+)
Please add the driver name, in this case mt76, as a prefix in the title.
For example the title could be:
mt76: mt7615: add TX/RX antenna pattern capabilities
mt76: add TX/RX antenna pattern capabilities for mt7615
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] mt76: mt7615: add TX/RX antenna pattern capabilities
From: Ryder Lee @ 2019-04-26 5:23 UTC (permalink / raw)
To: Lorenzo Bianconi, Felix Fietkau
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, linux-wireless,
linux-mediatek, linux-kernel, Ryder Lee
Announce antenna pattern cap to adapt PHY and baseband settings.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v2:
- Add a prefix mt76 in the title.
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 3ab3ff553ef2..122f7a565540 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -190,6 +190,8 @@ int mt7615_register_device(struct mt7615_dev *dev)
IEEE80211_VHT_CAP_SHORT_GI_160 |
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454 |
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK |
+ IEEE80211_VHT_CAP_RX_ANTENNA_PATTERN |
+ IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN |
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
dev->mt76.chainmask = 0x404;
dev->mt76.antenna_mask = 0xf;
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Ingo Molnar @ 2019-04-26 6:00 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425202226.GD64477@romley-ivt3.sc.intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Apr 25, 2019 at 10:08:30PM +0200, Ingo Molnar wrote:
> >
> > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> >
> > > On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> > > >
> > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > >
> > > > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > > > >
> > > > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > > > >
> > > > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > > > When the bit is 0, split lock detection is not supported.
> > > > > > >
> > > > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > > > split lock detection bit.
> > > > > > >
> > > > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > > > ---
> > > > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > > > 1 file changed, 3 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > > > @@ -59,6 +59,9 @@
> > > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > > > >
> > > > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > > > >
> > > > > > Please don't put comments into definitions.
> > > > >
> > > > > I'll remove the comment and change definitions of the MSR and the split lock
> > > > > detection bit as following:
> > > > >
> > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > > > >
> > > > > Are these right changes?
> > > >
> > > > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > > > originally.
> > >
> > > IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> > > https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
> > >
> > > So can I define the MSR and the bits as follows?
> > >
> > > +#define MSR_IA32_CORE_CAP 0x000000cf
> > > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> > > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
> >
> > Yeah, I suppose that looks OK.
>
> Should I also change the feature definition 'X86_FEATURE_CORE_CAPABILITY' to
> 'X86_FEATURE_CORE_CAP' in cpufeatures.h in patch #0006 to match the
> MSR definition here? Or should I still keep the current feature definition?
>
> Thanks.
Hm, no, for CPU features it's good to follow the vendor convention.
So I guess the long-form CPU_CAPABILITY for all of these is the best
after all.
Thanks,
Ingo
^ permalink raw reply
* [PATCH 0/5] ath10k: implement PN replay protection for SDIO
From: Kalle Valo @ 2019-04-26 6:41 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
HTT High Latency devices (SDIO and USB) need PN replay protection in
host driver, implemented in this patchset. Also support for QCA6174
hw3.2 SDIO devices is enabled as now all the necessary pieces have now
been implemented.
For replay protection of TKIP, CCMP and GCMP
ath10k_htt_rx_pn_check_replay_hl() will check PN to see if the frame
is received before. This is implemented in patch "ath10k: add PN
replay protection for high latency devices"
The replay protection on fragmented MSDU with CCMP and GCMP is done by
ath10k_htt_rx_proc_rx_frag_ind_hl(), implemented in patch "ath10k: add
fragment packet handler for high latency". The fragments will be
reassembled by mac80211 in ieee80211_rx_h_defragment(). Also mac80211
will verify the Michael MIC in ieee80211_rx_h_michael_mic_verify().
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Wen Gong (5):
ath10k: add struct for high latency PN replay protection
ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event
ath10k: add PN replay protection for high latency devices
ath10k: add fragmentation handler for high latency devices
ath10k: enable QCA6174 hw3.2 SDIO hardware
drivers/net/wireless/ath/ath10k/core.c | 27 +++
drivers/net/wireless/ath/ath10k/core.h | 8 +
drivers/net/wireless/ath/ath10k/htt.h | 56 ++++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 373 ++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
6 files changed, 460 insertions(+), 7 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/5] ath10k: add struct for high latency PN replay protection
From: Kalle Valo @ 2019-04-26 6:41 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Wen Gong
In-Reply-To: <1556260871-2919-1-git-send-email-kvalo@codeaurora.org>
From: Wen Gong <wgong@codeaurora.org>
Add the struct for PN replay protection and fragment packet
handler.
Also fix the bitmask of HTT_RX_DESC_HL_INFO_MCAST_BCAST to match what's currently
used by SDIO firmware. The defines are not used yet so it's safe to modify
them. Remove the conflicting HTT_RX_DESC_HL_INFO_FRAGMENT as
it's not either used in ath10k.
Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.h | 8 +++++++
drivers/net/wireless/ath/ath10k/htt.h | 43 ++++++++++++++++++++++++++++++----
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f22cb3f49034..02e53fb85814 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -400,6 +400,14 @@ struct ath10k_peer {
/* protected by ar->data_lock */
struct ieee80211_key_conf *keys[WMI_MAX_KEY_INDEX + 1];
+ union htt_rx_pn_t tids_last_pn[ATH10K_TXRX_NUM_EXT_TIDS];
+ bool tids_last_pn_valid[ATH10K_TXRX_NUM_EXT_TIDS];
+ union htt_rx_pn_t frag_tids_last_pn[ATH10K_TXRX_NUM_EXT_TIDS];
+ u32 frag_tids_seq[ATH10K_TXRX_NUM_EXT_TIDS];
+ struct {
+ enum htt_security_types sec_type;
+ int pn_len;
+ } rx_pn[ATH10K_HTT_TXRX_PEER_SECURITY_MAX];
};
struct ath10k_txq {
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 4cee5492abc8..fb5cb9169073 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -733,6 +733,20 @@ struct htt_rx_indication_hl {
struct htt_rx_indication_mpdu_range mpdu_ranges[0];
} __packed;
+struct htt_hl_rx_desc {
+ __le32 info;
+ __le32 pn_31_0;
+ union {
+ struct {
+ __le16 pn_47_32;
+ __le16 pn_63_48;
+ } pn16;
+ __le32 pn_63_32;
+ } u0;
+ __le32 pn_95_64;
+ __le32 pn_127_96;
+} __packed;
+
static inline struct htt_rx_indication_mpdu_range *
htt_rx_ind_get_mpdu_ranges(struct htt_rx_indication *rx_ind)
{
@@ -790,6 +804,21 @@ struct htt_rx_peer_unmap {
__le16 peer_id;
} __packed;
+enum htt_txrx_sec_cast_type {
+ HTT_TXRX_SEC_MCAST = 0,
+ HTT_TXRX_SEC_UCAST
+};
+
+enum htt_rx_pn_check_type {
+ HTT_RX_NON_PN_CHECK = 0,
+ HTT_RX_PN_CHECK
+};
+
+enum htt_rx_tkip_demic_type {
+ HTT_RX_NON_TKIP_MIC = 0,
+ HTT_RX_TKIP_MIC
+};
+
enum htt_security_types {
HTT_SECURITY_NONE,
HTT_SECURITY_WEP128,
@@ -803,6 +832,9 @@ enum htt_security_types {
HTT_NUM_SECURITY_TYPES /* keep this last! */
};
+#define ATH10K_HTT_TXRX_PEER_SECURITY_MAX 2
+#define ATH10K_TXRX_NUM_EXT_TIDS 19
+
enum htt_security_flags {
#define HTT_SECURITY_TYPE_MASK 0x7F
#define HTT_SECURITY_TYPE_LSB 0
@@ -1010,6 +1042,11 @@ struct htt_rx_fragment_indication {
u8 fw_msdu_rx_desc[0];
} __packed;
+#define ATH10K_IEEE80211_EXTIV BIT(5)
+#define ATH10K_IEEE80211_TKIP_MICLEN 8 /* trailing MIC */
+
+#define HTT_RX_FRAG_IND_INFO0_HEADER_LEN 16
+
#define HTT_RX_FRAG_IND_INFO0_EXT_TID_MASK 0x1F
#define HTT_RX_FRAG_IND_INFO0_EXT_TID_LSB 0
#define HTT_RX_FRAG_IND_INFO0_FLUSH_VALID_MASK 0x20
@@ -2128,10 +2165,8 @@ struct htt_rx_desc {
#define HTT_RX_DESC_HL_INFO_ENCRYPTED_LSB 12
#define HTT_RX_DESC_HL_INFO_CHAN_INFO_PRESENT_MASK 0x00002000
#define HTT_RX_DESC_HL_INFO_CHAN_INFO_PRESENT_LSB 13
-#define HTT_RX_DESC_HL_INFO_MCAST_BCAST_MASK 0x00008000
-#define HTT_RX_DESC_HL_INFO_MCAST_BCAST_LSB 15
-#define HTT_RX_DESC_HL_INFO_FRAGMENT_MASK 0x00010000
-#define HTT_RX_DESC_HL_INFO_FRAGMENT_LSB 16
+#define HTT_RX_DESC_HL_INFO_MCAST_BCAST_MASK 0x00010000
+#define HTT_RX_DESC_HL_INFO_MCAST_BCAST_LSB 16
#define HTT_RX_DESC_HL_INFO_KEY_ID_OCT_MASK 0x01fe0000
#define HTT_RX_DESC_HL_INFO_KEY_ID_OCT_LSB 17
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event
From: Kalle Valo @ 2019-04-26 6:41 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Wen Gong
In-Reply-To: <1556260871-2919-1-git-send-email-kvalo@codeaurora.org>
From: Wen Gong <wgong@codeaurora.org>
Add the handler for HTT_T2H_MSG_TYPE_SEC_IND event from firmware, which stores
PN for replay check implemented in the following patch.
Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 46 ++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index f22840bbc389..cc2875d73bf0 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -3267,6 +3267,51 @@ static void ath10k_fetch_10_2_tx_stats(struct ath10k *ar, u8 *data)
rcu_read_unlock();
}
+static int ath10k_htt_rx_pn_len(enum htt_security_types sec_type)
+{
+ switch (sec_type) {
+ case HTT_SECURITY_TKIP:
+ case HTT_SECURITY_TKIP_NOMIC:
+ case HTT_SECURITY_AES_CCMP:
+ return 48;
+ default:
+ return 0;
+ }
+}
+
+static void ath10k_htt_rx_sec_ind_handler(struct ath10k *ar,
+ struct htt_security_indication *ev)
+{
+ enum htt_txrx_sec_cast_type sec_index;
+ enum htt_security_types sec_type;
+ struct ath10k_peer *peer;
+
+ spin_lock_bh(&ar->data_lock);
+
+ peer = ath10k_peer_find_by_id(ar, __le16_to_cpu(ev->peer_id));
+ if (!peer) {
+ ath10k_warn(ar, "failed to find peer id %d for security indication",
+ __le16_to_cpu(ev->peer_id));
+ goto out;
+ }
+
+ sec_type = MS(ev->flags, HTT_SECURITY_TYPE);
+
+ if (ev->flags & HTT_SECURITY_IS_UNICAST)
+ sec_index = HTT_TXRX_SEC_UCAST;
+ else
+ sec_index = HTT_TXRX_SEC_MCAST;
+
+ peer->rx_pn[sec_index].sec_type = sec_type;
+ peer->rx_pn[sec_index].pn_len = ath10k_htt_rx_pn_len(sec_type);
+
+ memset(peer->tids_last_pn_valid, 0, sizeof(peer->tids_last_pn_valid));
+ memset(peer->tids_last_pn, 0, sizeof(peer->tids_last_pn));
+
+out:
+ spin_unlock_bh(&ar->data_lock);
+}
+
bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
{
struct ath10k_htt *htt = &ar->htt;
@@ -3360,6 +3405,7 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
struct ath10k *ar = htt->ar;
struct htt_security_indication *ev = &resp->security_indication;
+ ath10k_htt_rx_sec_ind_handler(ar, ev);
ath10k_dbg(ar, ATH10K_DBG_HTT,
"sec ind peer_id %d unicast %d type %d\n",
__le16_to_cpu(ev->peer_id),
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox