<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/broadcom, branch v5.4.113</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-04-07T12:47:41+00:00</updated>
<entry>
<title>brcmfmac: clear EAP/association status bits on linkdown events</title>
<updated>2021-04-07T12:47:41+00:00</updated>
<author>
<name>Luca Pesce</name>
<email>luca.pesce@vimar.com</email>
</author>
<published>2020-12-24T10:51:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b8dfb61f29a56fe4f44e2ced6d216bd494f2781'/>
<id>urn:sha1:0b8dfb61f29a56fe4f44e2ced6d216bd494f2781</id>
<content type='text'>
[ Upstream commit e862a3e4088070de352fdafe9bd9e3ae0a95a33c ]

This ensure that previous association attempts do not leave stale statuses
on subsequent attempts.

This fixes the WARN_ON(!cr-&gt;bss)) from __cfg80211_connect_result() when
connecting to an AP after a previous connection failure (e.g. where EAP fails
due to incorrect psk but association succeeded). In some scenarios, indeed,
brcmf_is_linkup() was reporting a link up event too early due to stale
BRCMF_VIF_STATUS_ASSOC_SUCCESS bit, thus reporting to cfg80211 a connection
result with a zeroed bssid (vif-&gt;profile.bssid is still empty), causing the
WARN_ON due to the call to cfg80211_get_bss() with the empty bssid.

Signed-off-by: Luca Pesce &lt;luca.pesce@vimar.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/1608807119-21785-1-git-send-email-luca.pesce@vimar.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Add DMI nvram filename quirk for Voyo winpad A15 tablet</title>
<updated>2021-03-07T11:20:45+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-01-29T17:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1b9c1c9dbb01b647ad8505e6dd1a96e10c76297'/>
<id>urn:sha1:e1b9c1c9dbb01b647ad8505e6dd1a96e10c76297</id>
<content type='text'>
[ Upstream commit a338c874d3d9d2463f031e89ae14942929b93db6 ]

The Voyo winpad A15 tablet contains quite generic names in the sys_vendor
and product_name DMI strings, without this patch brcmfmac will try to load:
rcmfmac4330-sdio.To be filled by O.E.M.-To be filled by O.E.M..txt
as nvram file which is a bit too generic.

Add a DMI quirk so that a unique and clearly identifiable nvram file name
is used on the Voyo winpad A15 tablet.

While preparing a matching linux-firmware update I noticed that the nvram
is identical to the nvram used on the Prowise-PT301 tablet, so the new DMI
quirk entry simply points to the already existing Prowise-PT301 nvram file.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20210129171413.139880-2-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Add DMI nvram filename quirk for Predia Basic tablet</title>
<updated>2021-03-07T11:20:45+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-01-29T17:14:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c099c272eb5e8149ab418ad904a9474a8638559'/>
<id>urn:sha1:3c099c272eb5e8149ab418ad904a9474a8638559</id>
<content type='text'>
[ Upstream commit af4b3a6f36d6c2fc5fca026bccf45e0fdcabddd9 ]

The Predia Basic tablet contains quite generic names in the sys_vendor and
product_name DMI strings, without this patch brcmfmac will try to load:
brcmfmac43340-sdio.Insyde-CherryTrail.txt as nvram file which is a bit
too generic.

Add a DMI quirk so that a unique and clearly identifiable nvram file name
is used on the Predia Basic tablet.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20210129171413.139880-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>b43: N-PHY: Fix the update of coef for the PHY revision &gt;= 3case</title>
<updated>2021-03-04T09:26:17+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2021-02-15T12:05:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8022d52a102bb145b70a42003690bd6031245a2a'/>
<id>urn:sha1:8022d52a102bb145b70a42003690bd6031245a2a</id>
<content type='text'>
[ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ]

The documentation for the PHY update [1] states:

Loop 4 times with index i

    If PHY Revision &gt;= 3
        Copy table[i] to coef[i]
    Otherwise
        Set coef[i] to 0

the copy of the table to coef is currently implemented the wrong way
around, table is being updated from uninitialized values in coeff.
Fix this by swapping the assignment around.

[1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/

Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration")
Addresses-Coverity: ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix memory leak for unpaired brcmf_{alloc/free}</title>
<updated>2020-12-30T10:51:05+00:00</updated>
<author>
<name>Seung-Woo Kim</name>
<email>sw0312.kim@samsung.com</email>
</author>
<published>2020-10-28T01:52:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8f14da44523c8944202bb06f77eb92bcb4e9efcf'/>
<id>urn:sha1:8f14da44523c8944202bb06f77eb92bcb4e9efcf</id>
<content type='text'>
[ Upstream commit 9db946284e07bb27309dd546b7fee528664ba82a ]

There are missig brcmf_free() for brcmf_alloc(). Fix memory leak
by adding missed brcmf_free().

Reported-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Fixes: a1f5aac1765a ("brcmfmac: don't realloc wiphy during PCIe reset")
Signed-off-by: Seung-Woo Kim &lt;sw0312.kim@samsung.com&gt;
Reviewed-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/1603849967-22817-1-git-send-email-sw0312.kim@samsung.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix warning message after dongle setup failed</title>
<updated>2020-11-05T10:43:19+00:00</updated>
<author>
<name>Wright Feng</name>
<email>wright.feng@cypress.com</email>
</author>
<published>2020-09-28T05:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=592cbc0a6a83c06e245365e127c5452a400c8aec'/>
<id>urn:sha1:592cbc0a6a83c06e245365e127c5452a400c8aec</id>
<content type='text'>
[ Upstream commit 6aa5a83a7ed8036c1388a811eb8bdfa77b21f19c ]

Brcmfmac showed warning message in fweh.c when checking the size of event
queue which is not initialized. Therefore, we only cancel the worker and
reset event handler only when it is initialized.

[  145.505899] brcmfmac 0000:02:00.0: brcmf_pcie_setup: Dongle setup
[  145.929970] ------------[ cut here ]------------
[  145.929994] WARNING: CPU: 0 PID: 288 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c:312
brcmf_fweh_detach+0xbc/0xd0 [brcmfmac]
...
[  145.930029] Call Trace:
[  145.930036]  brcmf_detach+0x77/0x100 [brcmfmac]
[  145.930043]  brcmf_pcie_remove+0x79/0x130 [brcmfmac]
[  145.930046]  pci_device_remove+0x39/0xc0
[  145.930048]  device_release_driver_internal+0x141/0x200
[  145.930049]  device_release_driver+0x12/0x20
[  145.930054]  brcmf_pcie_setup+0x101/0x3c0 [brcmfmac]
[  145.930060]  brcmf_fw_request_done+0x11d/0x1f0 [brcmfmac]
[  145.930062]  ? lock_timer_base+0x7d/0xa0
[  145.930063]  ? internal_add_timer+0x1f/0xa0
[  145.930064]  ? add_timer+0x11a/0x1d0
[  145.930066]  ? __kmalloc_track_caller+0x18c/0x230
[  145.930068]  ? kstrdup_const+0x23/0x30
[  145.930069]  ? add_dr+0x46/0x80
[  145.930070]  ? devres_add+0x3f/0x50
[  145.930072]  ? usermodehelper_read_unlock+0x15/0x20
[  145.930073]  ? _request_firmware+0x288/0xa20
[  145.930075]  request_firmware_work_func+0x36/0x60
[  145.930077]  process_one_work+0x144/0x360
[  145.930078]  worker_thread+0x4d/0x3c0
[  145.930079]  kthread+0x112/0x150
[  145.930080]  ? rescuer_thread+0x340/0x340
[  145.930081]  ? kthread_park+0x60/0x60
[  145.930083]  ret_from_fork+0x25/0x30

Signed-off-by: Wright Feng &lt;wright.feng@cypress.com&gt;
Signed-off-by: Chi-hsien Lin &lt;chi-hsien.lin@cypress.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200928054922.44580-3-wright.feng@cypress.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcm80211: fix possible memleak in brcmf_proto_msgbuf_attach</title>
<updated>2020-10-29T08:58:09+00:00</updated>
<author>
<name>Wang Yufen</name>
<email>wangyufen@huawei.com</email>
</author>
<published>2020-07-20T09:36:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5912b09c97cd5a04b9486a02abbcefad02aa73ef'/>
<id>urn:sha1:5912b09c97cd5a04b9486a02abbcefad02aa73ef</id>
<content type='text'>
[ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ]

When brcmf_proto_msgbuf_attach fail and msgbuf-&gt;txflow_wq != NULL,
we should destroy the workqueue.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Yufen &lt;wangyufen@huawei.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmsmac: fix memory leak in wlc_phy_attach_lcnphy</title>
<updated>2020-10-29T08:58:07+00:00</updated>
<author>
<name>Keita Suzuki</name>
<email>keitasuzuki.park@sslab.ics.keio.ac.jp</email>
</author>
<published>2020-09-08T12:17:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5eb55b5f96ff06587410c20bb95b8e8645a1737'/>
<id>urn:sha1:d5eb55b5f96ff06587410c20bb95b8e8645a1737</id>
<content type='text'>
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ]

When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
the allocated pi-&gt;u.pi_lcnphy is leaked, since struct brcms_phy will be
freed in the caller function.

Fix this by calling wlc_phy_detach_lcnphy in the error handler of
wlc_phy_txpwr_srom_read_lcnphy before returning.

Signed-off-by: Keita Suzuki &lt;keitasuzuki.park@sslab.ics.keio.ac.jp&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: check ndev pointer</title>
<updated>2020-10-29T08:57:36+00:00</updated>
<author>
<name>Tom Rix</name>
<email>trix@redhat.com</email>
</author>
<published>2020-08-02T16:18:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7bf50ff5a32cc2267f55266385d3a5ed472f23b1'/>
<id>urn:sha1:7bf50ff5a32cc2267f55266385d3a5ed472f23b1</id>
<content type='text'>
[ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ]

Clang static analysis reports this error

brcmfmac/core.c:490:4: warning: Dereference of null pointer
        (*ifp)-&gt;ndev-&gt;stats.rx_errors++;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this block of code

	if (ret || !(*ifp) || !(*ifp)-&gt;ndev) {
		if (ret != -ENODATA &amp;&amp; *ifp)
			(*ifp)-&gt;ndev-&gt;stats.rx_errors++;
		brcmu_pkt_buf_free_skb(skb);
		return -ENODATA;
	}

(*ifp)-&gt;ndev being NULL is caught as an error
But then it is used to report the error.

So add a check before using it.

Fixes: 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device")
Signed-off-by: Tom Rix &lt;trix@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200802161804.6126-1-trix@redhat.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: Fix double freeing in the fmac usb data path</title>
<updated>2020-10-01T11:17:49+00:00</updated>
<author>
<name>Raveendran Somu</name>
<email>raveendran.somu@cypress.com</email>
</author>
<published>2020-03-25T08:20:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ed8ad92378726b4f8e93abfa41086b08c0d8984'/>
<id>urn:sha1:1ed8ad92378726b4f8e93abfa41086b08c0d8984</id>
<content type='text'>
[ Upstream commit 78179869dc3f5c0059bbf5d931a2717f1ad97ecd ]

When the brcmf_fws_process_skb() fails to get hanger slot for
queuing the skb, it tries to free the skb.
But the caller brcmf_netdev_start_xmit() of that funciton frees
the packet on error return value.
This causes the double freeing and which caused the kernel crash.

Signed-off-by: Raveendran Somu &lt;raveendran.somu@cypress.com&gt;
Signed-off-by: Chi-hsien Lin &lt;chi-hsien.lin@cypress.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/1585124429-97371-3-git-send-email-chi-hsien.lin@cypress.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
