* 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 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 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 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] brcmfmac: send mailbox interrupt twice for specific hardware device
From: Kalle Valo @ 2019-04-25 16:59 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, Chi-Hsien Lin, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <1556175939-174559-1-git-send-email-wright.feng@cypress.com>
Wright Feng <Wright.Feng@cypress.com> wrote:
> 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>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Failed to compile:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c: In function 'brcmf_pcie_send_mb_data':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: error: 'core' undeclared (first use in this function); did you mean 'cred'?
core = brcmf_chip_get_core(devinfo->ci, BCMA_CORE_PCIE2);
^~~~
cred
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.o] Error 1
make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
make[3]: *** [drivers/net/wireless/broadcom] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10916093/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: add RT3883 support
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin, Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1556092164-23823-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> From: Gabor Juhos <juhosg@openwrt.org>
>
> Patch add support for RT3883 chip. Code was taken direclty
> from openwrt project and merge into one patch.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
d0e61a0f7cca rt2x00: add RT3883 support
--
https://patchwork.kernel.org/patch/10914303/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Hans de Goede
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Hans de Goede,
linux-wireless, brcm80211-dev-list.pdl, stable
In-Reply-To: <20190422204123.6123-1-hdegoede@redhat.com>
Hans de Goede <hdegoede@redhat.com> wrote:
> The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor
> and product_name DMI strings, without this patch brcmfmac will try to load:
> "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which
> is way too generic.
>
> The DMI strings on which we are matching are somewhat generic too, but
> "To be filled by O.E.M." is less common then "Default string" and the
> system-sku and bios-version strings are pretty unique. Beside the DMI
> strings we also check the wifi-module chip-id and revision. I'm confident
> that the combination of all this is unique.
>
> Both the T8 and T11 use the same wifi-module, this commit adds DMI
> quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt .
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
b1a0ba8f772d brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
--
https://patchwork.kernel.org/patch/10911607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: p54: drop device reference count if fails to enable device
From: Kalle Valo @ 2019-04-25 16:57 UTC (permalink / raw)
To: Pan Bian
Cc: Christian Lamparter, David S. Miller, linux-wireless, netdev,
linux-kernel, Pan Bian
In-Reply-To: <1555494083-130833-1-git-send-email-bianpan2016@163.com>
Pan Bian <bianpan2016@163.com> wrote:
> The function p54p_probe takes an extra reference count of the PCI
> device. However, the extra reference count is not dropped when it fails
> to enable the PCI device. This patch fixes the bug.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
8149069db818 p54: drop device reference count if fails to enable device
--
https://patchwork.kernel.org/patch/10905039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 wireless-drivers-next] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Kalle Valo @ 2019-04-25 16:56 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Ping-Ke Shih, David S. Miller, Larry Finger, linux-wireless,
netdev, linux-kernel, Gustavo A. R. Silva, Kees Cook
In-Reply-To: <20190416151722.GA31598@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Add missing break statement in order to prevent the code from falling
> through to case 0x1025, and erroneously setting rtlhal->oem_id to
> RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
> none of the cases in switch (rtlefuse->eeprom_smid) match.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
84242b82d81c rtlwifi: rtl8723ae: Fix missing break in switch statement
--
https://patchwork.kernel.org/patch/10903325/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: fix spelling mistake "capabilties" -> "capabilities"
From: Kalle Valo @ 2019-04-25 16:55 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190415142649.18452-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There various spelling mistakes in function names and in message
> text. Fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
3b989e58e88a mwifiex: fix spelling mistake "capabilties" -> "capabilities"
--
https://patchwork.kernel.org/patch/10900921/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190415103703.11254-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Fix spelling mistakes in rx stats text. I missed these from an earlier
> round of fixing the same spelling mistake.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
b9574ce1d05e iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
--
https://patchwork.kernel.org/patch/10900491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/1] mwifiex: add support for SD8987 chipset
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Tamás Szűcs
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Hemantkumar Suthar,
Tamás Szűcs
In-Reply-To: <20190414183641.7539-2-tszucs@protonmail.ch>
Tamás Szűcs wrote:
> This patch adds support for Marvell 88W8987 chipset with SDIO interface.
> Register offsets and supported feature flags are updated. The corresponding
> firmware image file shall be "mrvl/sd8987_uapsta.bin".
>
> Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch>
Patch applied to wireless-drivers-next.git, thanks.
938c7c80c78e mwifiex: add support for SD8987 chipset
--
https://patchwork.kernel.org/patch/10899927/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: Fix rate_idx underflow
From: Kalle Valo @ 2019-04-25 16:53 UTC (permalink / raw)
To: Petr Štetiar
Cc: linux-wireless, Lennert Buytenhek, Petr Štetiar, stable
In-Reply-To: <1555006410-6090-1-git-send-email-ynezz@true.cz>
Petr Štetiar wrote:
> It was reported on OpenWrt bug tracking system[1], that several users
> are affected by the endless reboot of their routers if they configure
> 5GHz interface with channel 44 or 48.
>
> The reboot loop is caused by the following excessive number of WARN_ON
> messages:
>
> WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
> ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
>
> as the messages are being correctly emitted by the following guard:
>
> case RX_ENC_LEGACY:
> if (WARN_ON(status->rate_idx >= sband->n_bitrates))
>
> as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
> simply converts previously used magic number to proper constant and
> guards against substraction which is leading to the currently observed
> underflow.
>
> 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
>
> Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive")
> Cc: <stable@vger.kernel.org>
> Tested-by: Eubert Bao <bunnier@gmail.com>
> Reported-by: Eubert Bao <bunnier@gmail.com>
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
Patch applied to wireless-drivers-next.git, thanks.
6b583201fa21 mwl8k: Fix rate_idx underflow
--
https://patchwork.kernel.org/patch/10896599/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Kalle Valo @ 2019-04-25 16:52 UTC (permalink / raw)
To: Yue Haibing; +Cc: linux-kernel, linux-wireless, davem, netdev, YueHaibing
In-Reply-To: <20190408034529.27500-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> Syzkaller report this:
>
> [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
> [ 1213.469530] #PF error: [normal kernel read fault]
> [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
> [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
> [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
> [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
> [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
> [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
> [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
> [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
> [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
> [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
> [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
> [ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
> [ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
> [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1213.473514] PKRU: 55555554
> [ 1213.473514] Call Trace:
> [ 1213.473514] led_trigger_register+0x112/0x3f0
> [ 1213.473514] led_trigger_register_simple+0x7a/0x110
> [ 1213.473514] ? 0xffffffffc1c10000
> [ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
> [ 1213.473514] do_one_initcall+0xbc/0x47d
> [ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
> [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
> [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
> [ 1213.473514] do_init_module+0x1b5/0x547
> [ 1213.473514] load_module+0x6405/0x8c10
> [ 1213.473514] ? module_frob_arch_sections+0x20/0x20
> [ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
> [ 1213.473514] ? find_held_lock+0x32/0x1c0
> [ 1213.473514] ? cap_capable+0x1ae/0x210
> [ 1213.473514] ? __do_sys_finit_module+0x162/0x190
> [ 1213.473514] __do_sys_finit_module+0x162/0x190
> [ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
> [ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
> [ 1213.473514] ? wait_for_completion+0x370/0x370
> [ 1213.473514] ? vfs_write+0x204/0x4a0
> [ 1213.473514] ? do_syscall_64+0x18/0x450
> [ 1213.473514] do_syscall_64+0x9f/0x450
> [ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 1213.473514] RIP: 0033:0x462e99
> [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
> [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
> [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
> [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
> [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
>
> If usb_register failed, no need to call led_trigger_register_simple.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 1264b951463a ("at76c50x-usb: add driver")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
09ac2694b047 at76c50x-usb: Don't register led_trigger if usb_register_driver failed
--
https://patchwork.kernel.org/patch/10888765/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: fix error handling in mwl8k_post_cmd()
From: Kalle Valo @ 2019-04-25 16:52 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Lennert Buytenhek, Alexey Khoroshilov, David S. Miller,
linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <1554499598-29351-1-git-send-email-khoroshilov@ispras.ru>
Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
> If pci_map_single() fails in mwl8k_post_cmd(),
> it returns -ENOMEM immediately, while cleanup is required.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Patch applied to wireless-drivers-next.git, thanks.
d1717282afd5 mwl8k: fix error handling in mwl8k_post_cmd()
--
https://patchwork.kernel.org/patch/10887851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] b43: Remove empty function lpphy_papd_cal()
From: Kalle Valo @ 2019-04-25 16:51 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger, Arnd Bergmann
In-Reply-To: <20190404184914.12819-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit d825db346270e ("b43: shut up clang -Wuninitialized variable
> warning"), the message noted that function lpphy_papd_cal() was empty
> and had an old TODO regarding its implementation. As the reverse
> engineering project that created the LP-PHY version of this driver
> has not been active for some time, it is safe to remove this empty
> function.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
b25105e126e7 b43: Remove empty function lpphy_papd_cal()
--
https://patchwork.kernel.org/patch/10886095/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: prevent an array overflow
From: Kalle Valo @ 2019-04-25 16:50 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amitkumar Karwar, Xinming Hu, Nishant Sarmukadam, Ganapathi Bhat,
linux-wireless, kernel-janitors
In-Reply-To: <20190404084423.GB20193@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The "rate_index" is only used as an index into the phist_data->rx_rate[]
> array in the mwifiex_hist_data_set() function. That array has
> MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
> debugfs information. The "rate_index" variable comes from the network
> skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
> it to prevent an array overflow.
>
> Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Patch applied to wireless-drivers-next.git, thanks.
b4c35c17227f mwifiex: prevent an array overflow
--
https://patchwork.kernel.org/patch/10885297/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] zd1211rw: use struct_size() helper
From: Kalle Valo @ 2019-04-25 16:50 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Daniel Drake, Ulrich Kunitz, David S. Miller, linux-wireless,
netdev, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20190403185905.GA8650@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace code of the following form:
>
> sizeof(struct usb_req_write_regs) + count * sizeof(struct reg_data)
>
> with:
>
> struct_size(req, reg_writes, count)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
0c7beb2db9a5 zd1211rw: use struct_size() helper
--
https://patchwork.kernel.org/patch/10884349/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] mwifiex: use struct_size() in kzalloc()
From: Kalle Valo @ 2019-04-25 16:45 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S. Miller, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20190403164052.GA26381@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable regd_size is not necessary,
> hence it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
ae187ba91541 mwifiex: use struct_size() in kzalloc()
--
https://patchwork.kernel.org/patch/10884249/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/8] rsi: add new device model for 9116
From: Kalle Valo @ 2019-04-25 16:45 UTC (permalink / raw)
To: Siva Rebbagondla
Cc: linux-wireless, amitkarwar, krishna.pedda, Ganapathiraju Kondraju,
Siva Rebbagondla
In-Reply-To: <20190403041309.12829-2-siva8118@gmail.com>
Siva Rebbagondla <siva8118@gmail.com> wrote:
> 9116 device id entry is added in both SDIO and USB interfaces.
> New enumberation value taken for the device model. Based on the
> device model detected run time, few device specific operations
> needs to be performed.
>
> adding rsi_dev_model to get device type in run time, as we can use
> same driver for 9113 and 9116 except few firmware load changes.
>
> Signed-off-by: Siva Rebbagondla <siva8118@gmail.com>
8 patches applied to wireless-drivers-next.git, thanks.
54fdb318c111 rsi: add new device model for 9116
3ac61578fbd4 rsi: move common part of firmware load to separate function
e5a1ecc97e5f rsi: add firmware loading for 9116 device
9ba4562ac195 rsi: change in device init frame sequence for 9116
f911c86166d5 rsi: new bootup parameters for 9116
1533f976c668 rsi: send new tx command frame wlan9116 features
17ff2c794f39 rsi: reset device changes for 9116
0a60014b76f5 rsi: miscallaneous changes for 9116 and common
--
https://patchwork.kernel.org/patch/10882717/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/8] rt2800: partially restore old mmio txstatus behaviour
From: Kalle Valo @ 2019-04-25 16:44 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <1553680711-15730-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Do not disable txstatus interrupt and add quota of processed tx statuses in
> one tasklet. Quota is needed to allow to fed device with new frames during
> processing of tx statuses.
>
> Patch fixes about 15% performance degradation on some scenarios caused by
> 0b0d556e0ebb ("rt2800mmio: use txdone/txstatus routines from lib").
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
8 patches applied to wireless-drivers-next.git, thanks.
889bb866baaf rt2800: partially restore old mmio txstatus behaviour
f61131505e85 rt2800: new flush implementation for SoC devices
6efa79876486 rt2800: move txstatus pending routine
2c7ba758cc4b rt2800mmio: fetch tx status changes
e5ceab9df437 rt2800mmio: use timer and work for handling tx statuses timeouts
eb662b1dc62e rt2x00: remove last_nostatus_check
d954f9e3fb42 rt2x00: remove not used entry field
9ea3812f015b rt2x00mmio: remove legacy comment
--
https://patchwork.kernel.org/patch/10873121/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rsi: Fix NULL pointer dereference in kmalloc
From: Kalle Valo @ 2019-04-25 16:42 UTC (permalink / raw)
To: Aditya Pakki
Cc: pakki001, kjlu, Amitkumar Karwar, Siva Rebbagondla,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190323204916.8368-1-pakki001@umn.edu>
Aditya Pakki <pakki001@umn.edu> wrote:
> kmalloc can fail in rsi_register_rates_channels but memcpy still attempts
> to write to channels. The patch replaces these calls with kmemdup and
> passes the error upstream.
>
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Patch applied to wireless-drivers-next.git, thanks.
d5414c2355b2 rsi: Fix NULL pointer dereference in kmalloc
--
https://patchwork.kernel.org/patch/10866983/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Al Viro @ 2019-04-25 16:42 UTC (permalink / raw)
To: Arnd Bergmann
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, Apr 25, 2019 at 05:55:23PM +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, but not
> copy_to_user(), which overwrites 4 bytes after the end of
> the 20-byte user structure.
D'oh! FWIW, it might be worth putting into Documentation/ somewhere;
basically, what is and what isn't biarch-neutral.
Or arch-neutral, for that matter - it's very close. The only real
exception, IIRC, is an extra twist on m68k, where int behaves
like x86 long long - its alignment is only half its size, so
sizeof(struct {char c; int x;}) is 6, not 8 as everywhere
else. Irrelevant for biarch, thankfully (until somebody gets insane
enough to implement 64bit coldfire, kernel port for it *and* biarch
support for m68k binaries on that thing, that is)...
^ permalink raw reply
* Re: [PATCH] rt2x00: code-style fix in rt2800usb.c
From: Kalle Valo @ 2019-04-25 16:41 UTC (permalink / raw)
To: Tomislav Požega; +Cc: linux-wireless
In-Reply-To: <1552573160-3268-1-git-send-email-pozega.tomislav@gmail.com>
Tomislav Požega wrote:
> Remove space leftovers.
>
> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
9490c5602445 rt2x00: code-style fix in rt2800usb.c
--
https://patchwork.kernel.org/patch/10852955/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 2/4] rt2x00: use ratelimited variants dev_warn/dev_err
From: Kalle Valo @ 2019-04-25 16:41 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <1552384303-29529-3-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> As reported by Randy we can overwhelm logs on some USB error conditions.
> To avoid that use dev_warn_ratelimited() and dev_err_ratelimitd().
>
> Reported-and-tested-by: Randy Oostdyk <linux-kernel@oostdyk.com>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
3 patches applied to wireless-drivers-next.git, thanks.
bb3b18c92533 rt2x00: use ratelimited variants dev_warn/dev_err
e383c70474db rt2x00: check number of EPROTO errors
61a4e5ff0d72 rt2x00: do not print error when queue is full
--
https://patchwork.kernel.org/patch/10848959/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
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