[PATCH] brcmsmac: allocate ucode with GFP_KERNEL
The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup()
with GFP_ATOMIC as a precondition of wl->lock acquired. This caused
allocation failures sometimes as reported in the bugzilla below.
When looking at the the real usage, one can find that it's called
solely from brcms_request_fw(), and it's obviously outside the lock.
Hence we can use GFP_KERNEL there safely for avoiding such allocation
errors.
Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1085174
Signed-off-by: Takashi Iwai <ti...@suse.de>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
index ddfdfe177e24..a14fccf8a902 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c
@@ -1563,7 +1563,7 @@ void brcms_free_timer(struct brcms_timer *t)
}
/*
- * precondition: perimeter lock has been acquired
+ * precondition: no locking required
*/
int brcms_ucode_init_buf(struct brcms_info *wl, void **pbuf, u32 idx)
{
@@ -1578,7 +1578,7 @@ int brcms_ucode_init_buf(struct brcms_info *wl, void
**pbuf, u32 idx)
if (le32_to_cpu(hdr->idx) == idx) {
pdata = wl->fw.fw_bin[i]->data +
le32_to_cpu(hdr->offset);
- *pbuf = kmemdup(pdata, len, GFP_ATOMIC);
+ *pbuf = kmemdup(pdata, len, GFP_KERNEL);
if (*pbuf == NULL)
goto fail;
--
2.16.2
Re: [alsa-devel] [trivial PATCH] treewide: Align function definition open/close braces
On Mon, 18 Dec 2017 01:28:44 +0100, Joe Perches wrote: > > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. > > This allows various function analyzers like gnu complexity to work > properly for these modified functions. > > Miscellanea: > > o Remove extra trailing ; and blank line from xfs_agf_verify > > Signed-off-by: Joe Perches <j...@perches.com> > --- > git diff -w shows no difference other than the above 'Miscellanea' > > (this is against -next, but it applies against Linus' tree > with a couple offsets) > > arch/x86/include/asm/atomic64_32.h | 2 +- > drivers/acpi/custom_method.c | 2 +- > drivers/acpi/fan.c | 2 +- > drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +- > drivers/media/i2c/msp3400-kthreads.c | 2 +- > drivers/message/fusion/mptsas.c | 2 +- > drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +- > drivers/net/wireless/ath/ath9k/xmit.c| 2 +- > drivers/platform/x86/eeepc-laptop.c | 2 +- > drivers/rtc/rtc-ab-b5ze-s3.c | 2 +- > drivers/scsi/dpt_i2o.c | 2 +- > drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +- > fs/locks.c | 2 +- > fs/ocfs2/stack_user.c| 2 +- > fs/xfs/libxfs/xfs_alloc.c| 5 ++--- > fs/xfs/xfs_export.c | 2 +- > kernel/audit.c | 6 +++--- > kernel/trace/trace_printk.c | 4 ++-- > lib/raid6/sse2.c | 14 +++--- > sound/soc/fsl/fsl_dma.c | 2 +- For sound bits, Acked-by: Takashi Iwai <ti...@suse.de> thanks, Takashi
Re: [PATCH] b43: Add missing MODULE_FIRMWARE()
On Thu, 04 May 2017 11:43:14 +0200,
Kalle Valo wrote:
>
> Takashi Iwai <ti...@suse.de> writes:
>
> > Some recent firmware entries were forgotten to be added via
> > MODULE_FIRMWARE(), which may result in the non-functional state when
> > the driver is loaded in initrd.
> >
> > Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
> > Signed-off-by: Takashi Iwai <ti...@suse.de>
>
> With recent you mean three years ago? ;)
Heh, time flies :)
> Some of these were added by
> Rafal (CCed) in commit 15be8e89cdd99 and some in a60f99f75dd35.
>
> I'll replace the word recent and add:
>
> Fixes: 15be8e89cdd9 ("b43: add more bcma cores")
>
> But as this is so old bug I'll queue this to 4.13.
Thanks, it's no urgent fix, obviously. We just stumbled on this
casually.
Takashi
MODULE_FIRMWARE() for fallback ucode files?
Hi, currently iwlwifi driver lists only the latest firmware files in MODULE_FIRMWARE() although the driver may read other older files. And this confuses the openSUSE installer, since the installation image is created based on the module information and copies only the firmwares listed there. A bug report is found at: https://bugzilla.suse.com/show_bug.cgi?id=1021082 Would it be better to list up all firmware files? Or how can we inform user-space which firmware files would be possibly loaded? In anyway, the current situation is messy. The driver declares the firmware files that don't exist in the common linux-firmware git tree. If we list up only the latest API version, we should guarantee that these files are landed in the official tree before upstreaming. thanks, Takashi
Re: Non-working mwifiex_sdio with SD8897
On Thu, 08 Dec 2016 11:18:23 +0100, Takashi Iwai wrote: > > Hi Amitkumar, > > On Thu, 08 Dec 2016 06:40:48 +0100, > Amitkumar Karwar wrote: > > > > Hi Takashi, > > > > > From: Takashi Iwai [mailto:ti...@suse.de] > > > Sent: Friday, December 02, 2016 10:19 PM > > > To: Amitkumar Karwar; Nishant Sarmukadam > > > Cc: linux-wireless@vger.kernel.org; Oliver Neukum > > > Subject: Non-working mwifiex_sdio with SD8897 > > > > > > Hi, > > > > > > we've got an Intel Cherry Trail-based system with Marvell SD8897 chip > > > over MMC (sdhci), and WiFi / BT always fails at starting (or better to > > > say, it never worked properly). > > > > > > For avoiding the race between WiFi and BT, I blacklisted btmrvl_sdio, > > > so let's concentrate only on mwifiex_sdio now. > > > > > > At the beginning of the driver loading, it looks fine: > > > > > > mwifiex_sdio mmc1:0001:1: info: FW download over, size 802164 bytes > > > mwifiex_sdio mmc1:0001:1: WLAN FW is active mwifiex_sdio mmc1:0001:1: > > > info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) mwifiex_sdio > > > mmc1:0001:1: driver_version = mwifiex 1.0 (15.68.7.p77) > > > cfg80211: Regulatory domain changed to country: US . > > > > > > Then it gets a timeout > > > > > > mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = > > > 0x107, act = 0x0 mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0 > > > mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0 mwifiex_sdio > > > mmc1:0001:1: is_cmd_timedout = 1 mwifiex_sdio mmc1:0001:1: > > > num_tx_timeout = 0 mwifiex_sdio mmc1:0001:1: last_cmd_index = 4 > > > mwifiex_sdio mmc1:0001:1: last_cmd_id: 1e 00 0c 01 1e 00 20 00 07 01 > > > mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 01 00 00 00 08 00 00 00 > > > mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 3 mwifiex_sdio > > > mmc1:0001:1: last_cmd_resp_id: 1e 80 0c 81 1e 80 20 80 20 80 > > > mwifiex_sdio mmc1:0001:1: last_event_index = 1 mwifiex_sdio > > > mmc1:0001:1: last_event: 00 00 0b 00 00 00 00 00 00 00 mwifiex_sdio > > > mmc1:0001:1: data_sent=0 cmd_sent=0 mwifiex_sdio mmc1:0001:1: > > > ps_mode=1 ps_state=1 mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo > > > dump start=== mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex > > > 1.0 (15.68.7.p77) mwifiex_sdio mmc1:0001:1: SDIO register dump start > > > mwifiex_sdio mmc1:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 > > > 03 00 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0x0-0xb): 02 ff c3 40 00 > > > 00 00 00 ff ff ff ff mwifiex_sdio mmc1:0001:1: SDIO Func1: (0x4c) 00 > > > (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 > > > mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 6c 00 10 00 3f > > > 36 36 02 20 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 76 > > > 00 1a 00 3f 36 36 02 20 mwifiex_sdio mmc1:0001:1: SDIO register dump > > > end mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump end=== > > > mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump start == > > > mwifiex_sdio mmc1:0001:1: Ignore scan. Card removed or firmware in bad > > > state mwifiex_sdio mmc1:0001:1: scan failed: -14 mwifiex_sdio > > > mmc1:0001:1: == mwifiex firmware dump end == mwifiex_sdio mmc1:0001:1: > > > == mwifiex dump information to /sys/class/devcoredump start > > > mwifiex_sdio mmc1:0001:1: == mwifiex dump information to > > > /sys/class/devcoredump end > > > > > > > Could you please try attached 7.p87 firmware? I will be submitting it > > upstream soon. > > Thanks! I tried it, but unfortunately the issue still remains. It seems that the problem is rather in the MMC / SDIO side. When the power management of the SD host PCI controller is turned off (i.e. echo on > /sys/devices/pci:00/:00:11.0/power/control), the WiFi starts working. I'm not sure whether it's a bug in sdhci driver or something else missing. In anyway, thank you for your help! Takashi
Re: Non-working mwifiex_sdio with SD8897
On Fri, 02 Dec 2016 17:49:13 +0100, Takashi Iwai wrote: > > Hi, > > we've got an Intel Cherry Trail-based system with Marvell SD8897 chip > over MMC (sdhci), and WiFi / BT always fails at starting (or better to > say, it never worked properly). > > For avoiding the race between WiFi and BT, I blacklisted btmrvl_sdio, > so let's concentrate only on mwifiex_sdio now. > > At the beginning of the driver loading, it looks fine: > > mwifiex_sdio mmc1:0001:1: info: FW download over, size 802164 bytes > mwifiex_sdio mmc1:0001:1: WLAN FW is active > mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) > mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (15.68.7.p77) > cfg80211: Regulatory domain changed to country: US > . > > Then it gets a timeout > > mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x107, > act = 0x0 > mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0 > mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0 > mwifiex_sdio mmc1:0001:1: is_cmd_timedout = 1 > mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0 > mwifiex_sdio mmc1:0001:1: last_cmd_index = 4 > mwifiex_sdio mmc1:0001:1: last_cmd_id: 1e 00 0c 01 1e 00 20 00 07 01 > mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 01 00 00 00 08 00 00 00 > mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 3 > mwifiex_sdio mmc1:0001:1: last_cmd_resp_id: 1e 80 0c 81 1e 80 20 80 20 80 > mwifiex_sdio mmc1:0001:1: last_event_index = 1 > mwifiex_sdio mmc1:0001:1: last_event: 00 00 0b 00 00 00 00 00 00 00 > mwifiex_sdio mmc1:0001:1: data_sent=0 cmd_sent=0 > mwifiex_sdio mmc1:0001:1: ps_mode=1 ps_state=1 > mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump start=== > mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) > mwifiex_sdio mmc1:0001:1: SDIO register dump start > mwifiex_sdio mmc1:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 03 > 00 > mwifiex_sdio mmc1:0001:1: SDIO Func1 (0x0-0xb): 02 ff c3 40 00 00 00 00 ff > ff ff ff > mwifiex_sdio mmc1:0001:1: SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) > 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 > mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 6c 00 10 00 3f 36 36 > 02 20 > mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 76 00 1a 00 3f 36 36 > 02 20 > mwifiex_sdio mmc1:0001:1: SDIO register dump end > mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump end=== > mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump start == > mwifiex_sdio mmc1:0001:1: Ignore scan. Card removed or firmware in bad state > mwifiex_sdio mmc1:0001:1: scan failed: -14 > mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump end == > mwifiex_sdio mmc1:0001:1: == mwifiex dump information to > /sys/class/devcoredump start > mwifiex_sdio mmc1:0001:1: == mwifiex dump information to > /sys/class/devcoredump end > > And the reset fails as well: > > mwifiex_sdio mmc1:0001:1: info: shutdown mwifiex... > mwifiex_sdio mmc1:0001:1: PREP_CMD: card is removed > mmc1: tried to reset card > mwifiex_sdio mmc1:0001:1: failed to enable function > > > I can give the output with CONFIG_MMC_DEBUG and dyndbg for mwifiex*, > but the full log is way too big to post, as the system is eMMC and it > contains lots of noises. In case it helps, the log snippet before the > timeout is like: > > [ 42.367403] mwifiex_sdio mmc1:0001:1: bgscan already stopped! > [ 42.398871] mmc1: starting CMD53 arg 93000100 flags 01b5 > [ 42.398880] mmc1: blksz 256 blocks 1 flags 0100 tsac 1000 ms nsac > 0 > [ 42.399136] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.400415] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.401787] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.403044] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.404498] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.405874] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.407192] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.408703] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.410229] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.411464] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.412754] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.414211] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.415365] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.416635] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.417968] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 > [ 42.419163] sdhci [sdhci_irq()]: *
Non-working mwifiex_sdio with SD8897
Hi, we've got an Intel Cherry Trail-based system with Marvell SD8897 chip over MMC (sdhci), and WiFi / BT always fails at starting (or better to say, it never worked properly). For avoiding the race between WiFi and BT, I blacklisted btmrvl_sdio, so let's concentrate only on mwifiex_sdio now. At the beginning of the driver loading, it looks fine: mwifiex_sdio mmc1:0001:1: info: FW download over, size 802164 bytes mwifiex_sdio mmc1:0001:1: WLAN FW is active mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (15.68.7.p77) cfg80211: Regulatory domain changed to country: US . Then it gets a timeout mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x107, act = 0x0 mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0 mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0 mwifiex_sdio mmc1:0001:1: is_cmd_timedout = 1 mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0 mwifiex_sdio mmc1:0001:1: last_cmd_index = 4 mwifiex_sdio mmc1:0001:1: last_cmd_id: 1e 00 0c 01 1e 00 20 00 07 01 mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 01 00 00 00 08 00 00 00 mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 3 mwifiex_sdio mmc1:0001:1: last_cmd_resp_id: 1e 80 0c 81 1e 80 20 80 20 80 mwifiex_sdio mmc1:0001:1: last_event_index = 1 mwifiex_sdio mmc1:0001:1: last_event: 00 00 0b 00 00 00 00 00 00 00 mwifiex_sdio mmc1:0001:1: data_sent=0 cmd_sent=0 mwifiex_sdio mmc1:0001:1: ps_mode=1 ps_state=1 mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump start=== mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) mwifiex_sdio mmc1:0001:1: SDIO register dump start mwifiex_sdio mmc1:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 03 00 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0x0-0xb): 02 ff c3 40 00 00 00 00 ff ff ff ff mwifiex_sdio mmc1:0001:1: SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 6c 00 10 00 3f 36 36 02 20 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 76 00 1a 00 3f 36 36 02 20 mwifiex_sdio mmc1:0001:1: SDIO register dump end mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump end=== mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump start == mwifiex_sdio mmc1:0001:1: Ignore scan. Card removed or firmware in bad state mwifiex_sdio mmc1:0001:1: scan failed: -14 mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump end == mwifiex_sdio mmc1:0001:1: == mwifiex dump information to /sys/class/devcoredump start mwifiex_sdio mmc1:0001:1: == mwifiex dump information to /sys/class/devcoredump end And the reset fails as well: mwifiex_sdio mmc1:0001:1: info: shutdown mwifiex... mwifiex_sdio mmc1:0001:1: PREP_CMD: card is removed mmc1: tried to reset card mwifiex_sdio mmc1:0001:1: failed to enable function I can give the output with CONFIG_MMC_DEBUG and dyndbg for mwifiex*, but the full log is way too big to post, as the system is eMMC and it contains lots of noises. In case it helps, the log snippet before the timeout is like: [ 42.367403] mwifiex_sdio mmc1:0001:1: bgscan already stopped! [ 42.398871] mmc1: starting CMD53 arg 93000100 flags 01b5 [ 42.398880] mmc1: blksz 256 blocks 1 flags 0100 tsac 1000 ms nsac 0 [ 42.399136] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.400415] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.401787] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.403044] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.404498] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.405874] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.407192] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.408703] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.410229] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.411464] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.412754] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.414211] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.415365] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.416635] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.417968] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.419163] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.420439] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.421891] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.423206] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.424531] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.425974] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.427268] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020 [ 42.428575] sdhci [sdhci_irq()]: *** mmc1 got interrupt:
