summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2020-11-05Merge v5.8.17, commit '6d07b544ce203a684d9ca52635dcf2f4fc89b7d4' into ↵Jason M. Bills240-1112/+2412
dev-5.8-intel
2020-10-30Merge tag 'v5.8.17' into dev-5.8Joel Stanley112-634/+1416
This is the 5.8.17 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2020-10-29net: korina: cast KSEG0 address to pointer in kfreeValentin Vidic1-2/+2
[ Upstream commit 3bd57b90554b4bb82dce638e0668ef9dc95d3e96 ] Fixes gcc warning: passing argument 1 of 'kfree' makes pointer from integer without a cast Fixes: 3af5f0f5c74e ("net: korina: fix kfree of rx/tx descriptor array") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr> Link: https://lore.kernel.org/r/20201018184255.28989-1-vvidic@valentin-vidic.from.hr Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n()Zekun Shen1-0/+8
[ Upstream commit bad60b8d1a7194df38fd7fe4b22f3f4dcf775099 ] The idx in __ath10k_htt_rx_ring_fill_n function lives in consistent dma region writable by the device. Malfunctional or malicious device could manipulate such idx to have a OOB write. Either by htt->rx_ring.netbufs_ring[idx] = skb; or by ath10k_htt_set_paddrs_ring(htt, paddr, idx); The idx can also be negative as it's signed, giving a large memory space to write to. It's possibly exploitable by corruptting a legit pointer with a skb pointer. And then fill skb with payload as rougue object. Part of the log here. Sometimes it appears as UAF when writing to a freed memory by chance. [ 15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0 [ 15.595483] #PF: supervisor write access in kernel mode [ 15.596250] #PF: error_code(0x0002) - not-present page [ 15.597013] PGD 0 P4D 0 [ 15.597395] Oops: 0002 [#1] SMP KASAN PTI [ 15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69 [ 15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] [ 15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcm80211: fix possible memleak in brcmf_proto_msgbuf_attachWang Yufen1-0/+2
[ Upstream commit 6c151410d5b57e6bb0d91a735ac511459539a7bf ] When brcmf_proto_msgbuf_attach fail and msgbuf->txflow_wq != NULL, we should destroy the workqueue. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237765-66238-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: don't call del_timer_sync() on uninitialized timerTetsuo Handa1-1/+2
[ Upstream commit 621a3a8b1c0ecf16e1e5667ea5756a76a082b738 ] syzbot is reporting that del_timer_sync() is called from mwifiex_usb_cleanup_tx_aggr() from mwifiex_unregister_dev() without checking timer_setup() from mwifiex_usb_tx_init() was called [1]. Ganapathi Bhat proposed a possibly cleaner fix, but it seems that that fix was forgotten [2]. "grep -FrB1 'del_timer' drivers/ | grep -FA1 '.function)'" says that currently there are 28 locations which call del_timer[_sync]() only if that timer's function field was initialized (because timer_setup() sets that timer's function field). Therefore, let's use same approach here. [1] https://syzkaller.appspot.com/bug?id=26525f643f454dd7be0078423e3cdb0d57744959 [2] https://lkml.kernel.org/r/CA+ASDXMHt2gq9Hy+iP_BYkWXsSreWdp3_bAfMkNcuqJ3K+-jbQ@mail.gmail.com Reported-by: syzbot <syzbot+dc4127f950da51639216@syzkaller.appspotmail.com> Cc: Ganapathi Bhat <ganapathi.bhat@nxp.com> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Brian Norris <briannorris@chromium.org> Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821082720.7716-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtl8xxxu: prevent potential memory leakChris Chiu1-1/+9
[ Upstream commit 86279456a4d47782398d3cb8193f78f672e36cac ] Free the skb if usb_submit_urb fails on rx_urb. And free the urb no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb. Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906040424.22022-1-chiu@endlessm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcmsmac: fix memory leak in wlc_phy_attach_lcnphyKeita Suzuki1-1/+3
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ] When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy, the allocated pi->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 <keitasuzuki.park@sslab.ics.keio.ac.jp> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: hif_usb: fix race condition between usb_get_urb() and ↵Brooke Basile1-0/+19
usb_kill_anchored_urbs() [ Upstream commit 03fb92a432ea5abe5909bca1455b7e44a9380480 ] Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor systems create a race condition in which usb_kill_anchored_urbs() deallocates the URB before the completer callback is called in usb_kill_urb(), resulting in a use-after-free. To fix this, add proper lock protection to usb_kill_urb() calls that can possibly run concurrently with usb_kill_anchored_urbs(). Reported-by: syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf Signed-off-by: Brooke Basile <brookebasile@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200911071427.32354-1-brookebasile@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29can: flexcan: flexcan_chip_stop(): add error handling and propagate error valueJoakim Zhang1-6/+28
[ Upstream commit 9ad02c7f4f279504bdd38ab706fdc97d5f2b2a9c ] This patch implements error handling and propagates the error value of flexcan_chip_stop(). This function will be called from flexcan_suspend() in an upcoming patch in some SoCs which support LPSR mode. Add a new function flexcan_chip_stop_disable_on_error() that tries to disable the chip even in case of errors. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> [mkl: introduce flexcan_chip_stop_disable_on_error() and use it in flexcan_close()] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200922144429.2613631-11-mkl@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: increse the size of rx buffer sizeTzu-En Huang1-2/+2
[ Upstream commit ee755732b7a16af018daa77d9562d2493fb7092f ] The vht capability of MAX_MPDU_LENGTH is 11454 in rtw88; however, the rx buffer size for each packet is 8192. When receiving packets that are larger than rx buffer size, it will leads to rx buffer ring overflow. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925061219.23754-2-tehuang@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: pci: Power cycle device during shutdownKai-Heng Feng1-0/+2
[ Upstream commit 44492e70adc8086c42d3745d21d591657a427f04 ] There are reports that 8822CE fails to work rtw88 with "failed to read DBI register" error. Also I have a system with 8723DE which freezes the whole system when the rtw88 is probing the device. According to [1], platform firmware may not properly power manage the device during shutdown. I did some expirements and putting the device to D3 can workaround the issue. So let's power cycle the device by putting the device to D3 at shutdown to prevent the issue from happening. [1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9 BugLink: https://bugs.launchpad.net/bugs/1872984 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928165508.20775-1-kai.heng.feng@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29netsec: ignore 'phy-mode' device property on ACPI systemsArd Biesheuvel1-7/+17
[ Upstream commit acd7aaf51b20263a7e62d2a26569988c63bdd3d8 ] Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: korina: fix kfree of rx/tx descriptor arrayValentin Vidic1-1/+2
[ Upstream commit 3af5f0f5c74ecbaf757ef06c3f80d56751277637 ] kmalloc returns KSEG0 addresses so convert back from KSEG1 in kfree. Also make sure array is freed when the driver is unloaded from the kernel. Fixes: ef11291bcd5f ("Add support the Korina (IDT RC32434) Ethernet MAC") Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: fix double freeTom Rix1-0/+2
[ Upstream commit 53708f4fd9cfe389beab5c8daa763bcd0e0b4aef ] clang static analysis reports this problem: sdio.c:2403:3: warning: Attempt to free released memory kfree(card->mpa_rx.buf); ^~~~~~~~~~~~~~~~~~~~~~~ When mwifiex_init_sdio() fails in its first call to mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it again. If the second alloc of mpa_tx.buf fails, the error handler will try to free the old, previously freed mpa_rx.buf. Reviewing the code, it looks like a second double free would happen with mwifiex_cleanup_sdio(). So set both pointers to NULL when they are freed. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201004131931.29782-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: dbg: run init_cfg function once per driver loadMordechay Goodstein1-0/+3
[ Upstream commit 42f8a2735cc218b6b372134684d4cd3c1423f123 ] Every time we call init_cfg driver appends the enabled triggers to the active triggers while this should be done only once per driver load. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: 14124b25780d ("iwlwifi: dbg_ini: implement monitor allocation flow") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.79bd622e604a.Ie0f79d2ea90ca5cdf363f56194ead81b0a2c6202@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: dbg: remove no filter conditionMordechay Goodstein1-3/+2
[ Upstream commit bfdb157127dab2a85d4096a68a00ad568c9eb590 ] Currently if group-id and command-id values are zero we trigger and collect every RX frame, this is not the right behavior and zero value should be handled like any other filter. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: 3ed34fbf9d3b ("iwlwifi: dbg_ini: support FW response/notification region type") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930161256.6a0aae2c0507.I7bd72968279d586af420472707d53106b35efc08@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29iwlwifi: mvm: split a print to avoid a WARNING in ROCEmmanuel Grumbach1-3/+6
[ Upstream commit 903b3f9badf1d54f77b468b96706dab679b45b14 ] A print in the remain on channel code was too long and caused a WARNING, split it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: dc28e12f2125 ("iwlwifi: mvm: ROC: Extend the ROC max delay duration & limit ROC duration") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200930102759.58d57c0bdc68.Ib06008665e7bf1199c360aa92691d9c74fb84990@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: enic: Cure the enic api locking trainwreckThomas Gleixner3-6/+28
[ Upstream commit a53b59ece86c86d16d12ccdaa1ad0c78250a9d96 ] enic_dev_wait() has a BUG_ON(in_interrupt()). Chasing the callers of enic_dev_wait() revealed the gems of enic_reset() and enic_tx_hang_reset() which are both invoked through work queues in order to be able to call rtnl_lock(). So far so good. After locking rtnl both functions acquire enic::enic_api_lock which serializes against the (ab)use from infiniband. This is where the trainwreck starts. enic::enic_api_lock is a spin_lock() which implicitly disables preemption, but both functions invoke a ton of functions under that lock which can sleep. The BUG_ON(in_interrupt()) does not trigger in that case because it can't detect the preempt disabled condition. This clearly has never been tested with any of the mandatory debug options for 7+ years, which would have caught that for sure. Cure it by adding a enic_api_busy member to struct enic, which is modified and evaluated with enic::enic_api_lock held. If enic_api_devcmd_proxy_by_index() observes enic::enic_api_busy as true, it drops enic::enic_api_lock and busy waits for enic::enic_api_busy to become false. It would be smarter to wait for a completion of that busy period, but enic_api_devcmd_proxy_by_index() is called with other spin locks held which obviously can't sleep. Remove the BUG_ON(in_interrupt()) check as well because it's incomplete and with proper debugging enabled the problem would have been caught from the debug checks in schedule_timeout(). Fixes: 0b038566c0ea ("drivers/net: enic: Add an interface for USNIC to interact with firmware") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29qtnfmac: fix resource leaks on unsupported iftype error return pathColin Ian King1-0/+2
[ Upstream commit 63f6982075d890d7563e2469643f05a37d193f01 ] Currently if an unsupported iftype is detected the error return path does not free the cmd_skb leading to a resource leak. Fix this by free'ing cmd_skb. Addresses-Coverity: ("Resource leak") Fixes: 805b28c05c8e ("qtnfmac: prepare for AP_VLAN interface type support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925132224.21638-1-colin.king@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ibmvnic: set up 200GBPS speedLijun Pan2-2/+5
[ Upstream commit b9cd795b0e4860f482bf3741d12e1c8f3ec1cfc9 ] Set up the speed according to crq->query_phys_parms.rsp.speed. Fix IBMVNIC_10GBPS typo. Fixes: f8d6ae0d27ec ("ibmvnic: Report actual backing device speed and duplex values") Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mt76: mt7915: fix possible memory leak in mt7915_mcu_add_beaconLorenzo Bianconi1-8/+10
[ Upstream commit 071c8ce8e92a86b8bf78678e78eb4b79fdc16768 ] Release mcu message memory in case of failure in mt7915_mcu_add_beacon routine Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: Fix potential probe error handling race with wow firmware loadingAndreas Färber1-0/+3
[ Upstream commit ac4bac99161e8f7a7a9faef70d8ca8f69d5493a9 ] If rtw_core_init() fails to load the wow firmware, rtw_core_deinit() will not get called to clean up the regular firmware. Ensure that an error loading the wow firmware does not produce an oops for the regular firmware by waiting on its completion to be signalled before returning. Also release the loaded firmware. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Chin-Yen Lee <timlee@realtek.com> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200920132621.26468-3-afaerber@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: Fix probe error handling race with firmware loadingAndreas Färber1-0/+2
[ Upstream commit ecda9cda3338b594a1b82d62018c247132a39e57 ] In case of rtw8822be, a probe failure after successful rtw_core_init() has been observed to occasionally lead to an oops from rtw_load_firmware_cb(): [ 3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff0000 [ 3.930531] pci 0001:01:00.0: reg 0x10: [io 0x0000-0x00ff] [ 3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit] [ 3.944042] pci 0001:01:00.0: supports D1 D2 [ 3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x00010000 64bit] [ 3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x00010000 64bit] [ 3.972332] pci 0001:01:00.0: BAR 0: assigned [io 0x10000-0x100ff] [ 3.986240] rtw_8822be 0001:01:00.0: enabling device (0000 -> 0001) [ 3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory [ 3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region [ 4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources [ 4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12 [ 4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 4.050828] Unable to handle kernel paging request at virtual address edafeaac9607952c [ 4.058975] Mem abort info: [ 4.058980] ESR = 0x96000004 [ 4.058990] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.070353] SET = 0, FnV = 0 [ 4.073487] EA = 0, S1PTW = 0 [ 4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console [ 4.076723] Data abort info: [ 4.086415] ISV = 0, ISS = 0x00000004 [ 4.087731] Freeing unused kernel memory: 1792K [ 4.090391] CM = 0, WnR = 0 [ 4.098091] [edafeaac9607952c] address between user and kernel address ranges [ 4.105418] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 4.111129] Modules linked in: [ 4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915+ #700 [ 4.122386] Hardware name: Realtek Saola EVB (DT) [ 4.127223] Workqueue: events request_firmware_work_func [ 4.132676] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 4.138393] pc : rtw_load_firmware_cb+0x54/0xbc [ 4.143040] lr : request_firmware_work_func+0x44/0xb4 [ 4.148217] sp : ffff800010133d70 [ 4.151616] x29: ffff800010133d70 x28: 0000000000000000 [ 4.157069] x27: 0000000000000000 x26: 0000000000000000 [ 4.162520] x25: 0000000000000000 x24: 0000000000000000 [ 4.167971] x23: ffff00007ac21908 x22: ffff00007ebb2100 [ 4.173424] x21: ffff00007ad35880 x20: edafeaac96079504 [ 4.178877] x19: ffff00007ad35870 x18: 0000000000000000 [ 4.184328] x17: 00000000000044d8 x16: 0000000000004310 [ 4.189780] x15: 0000000000000800 x14: 00000000ef006305 [ 4.195231] x13: ffffffff00000000 x12: ffffffffffffffff [ 4.200682] x11: 0000000000000020 x10: 0000000000000003 [ 4.206135] x9 : 0000000000000000 x8 : ffff00007e73f680 [ 4.211585] x7 : 0000000000000000 x6 : ffff80001119b588 [ 4.217036] x5 : ffff00007e649c80 x4 : ffff00007e649c80 [ 4.222487] x3 : ffff80001119b588 x2 : ffff8000108d1718 [ 4.227940] x1 : ffff800011bd5000 x0 : ffff00007ac21600 [ 4.233391] Call trace: [ 4.235906] rtw_load_firmware_cb+0x54/0xbc [ 4.240198] request_firmware_work_func+0x44/0xb4 [ 4.245027] process_one_work+0x178/0x1e4 [ 4.249142] worker_thread+0x1d0/0x268 [ 4.252989] kthread+0xe8/0xf8 [ 4.256127] ret_from_fork+0x10/0x18 [ 4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681) [ 4.266049] ---[ end trace f822ebae1a8545c2 ]--- To avoid this, wait on the completion callbacks in rtw_core_deinit() before releasing firmware and continuing teardown. Note that rtw_wait_firmware_completion() was introduced with c8e5695eae9959fc5774c0f490f2450be8bad3de ("rtw88: load wowlan firmware if wowlan is supported"), so backports to earlier branches may need to inline wait_for_completion(&rtwdev->fw.completion) instead. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: wmi: prevent a shift wrapping bug in ath6kl_wmi_delete_pstream_cmd()Dan Carpenter1-0/+5
[ Upstream commit 6a950755cec1a90ddaaff3e4acb5333617441c32 ] The "tsid" is a user controlled u8 which comes from debugfs. Values more than 15 are invalid because "active_tsids" is a 16 bit variable. If the value of "tsid" is more than 31 then that leads to a shift wrapping bug. Fixes: 8fffd9e5ec9e ("ath6kl: Implement support for QOS-enable and QOS-disable from userspace") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200918142732.GA909725@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: Add checked value for ath11k_ahb_removeBo YU1-3/+7
[ Upstream commit 80b892fc8a90e91498babf0f6817139e5ec64b5c ] Return value form wait_for_completion_timeout should to be checked. This is detected by Coverity: #CID:1464479 (CHECKED_RETURN) Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Bo YU <tsu.yubo@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200621095136.7xdbzkthoxuw2qow@debian.debian-2 Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: dsa: rtl8366rb: Support all 4096 VLANsLinus Walleij1-1/+1
[ Upstream commit a7920efdd86d8a0d74402dbc80ead03b023294ba ] There is an off-by-one error in rtl8366rb_is_vlan_valid() making VLANs 0..4094 valid while it should be 1..4095. Fix it. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: dsa: rtl8366: Skip PVID setting if not requestedLinus Walleij1-0/+3
[ Upstream commit 3dfe8dde093a07e82fa472c0f8c29a7f6a2006a5 ] We go to lengths to determine whether the PVID should be set for this port or not, and then fail to take it into account. Fix this oversight. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: dsa: rtl8366: Refactor VLAN/PVID initLinus Walleij2-131/+146
[ Upstream commit 7e1301ed1881447d2a25f9c6423738c33cbca133 ] The VLANs and PVIDs on the RTL8366 utilizes a "member configuration" (MC) which is largely unexplained in the code. This set-up requires a special ordering: rtl8366_set_pvid() must be called first, followed by rtl8366_set_vlan(), else the MC will not be properly allocated. Relax this by factoring out the code obtaining an MC and reuse the helper in both rtl8366_set_pvid() and rtl8366_set_vlan() so we remove this strict ordering requirement. In the process, add some better comments and debug prints so people who read the code understand what is going on. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: dsa: rtl8366: Check validity of passed VLANsLinus Walleij1-0/+6
[ Upstream commit 6641a2c42b0a307b7638d10e5d4b90debc61389d ] The rtl8366_set_vlan() and rtl8366_set_pvid() get invalid VLANs tossed at it, especially VLAN0, something the hardware and driver cannot handle. Check validity and bail out like we do in the other callbacks. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: stmmac: use netif_tx_start|stop_all_queues() functionOng Boon Leong1-32/+1
[ Upstream commit 9f19306d166688a73356aa636c62e698bf2063cc ] The current implementation of stmmac_stop_all_queues() and stmmac_start_all_queues() will not work correctly when the value of tx_queues_to_use is changed through ethtool -L DEVNAME rx N tx M command. Also, netif_tx_start|stop_all_queues() are only needed in driver open() and close() only. Fixes: c22a3f48 net: stmmac: adding multiple napi mechanism Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Voon Weifeng <weifeng.voon@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: stmmac: Fix incorrect location to set real_num_rx|tx_queuesAashish Verma1-4/+4
[ Upstream commit 686cff3d7022ddf35d7e38bc80191eb92de5989a ] netif_set_real_num_tx_queues() & netif_set_real_num_rx_queues() should be used to inform network stack about the real Tx & Rx queue (active) number in both stmmac_open() and stmmac_resume(), therefore, we move the code from stmmac_dvr_probe() to stmmac_hw_setup(). Fixes: c02b7a914551 net: stmmac: use netif_set_real_num_{rx,tx}_queues Signed-off-by: Aashish Verma <aashishx.verma@intel.com> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net/mlx5: Don't call timecounter cyc2time directly from 1PPS flowEran Ben Elisha1-2/+3
[ Upstream commit 0d2ffdc8d4002a62de31ff7aa3bef28c843c3cbe ] Before calling timecounter_cyc2time(), clock->lock must be taken. Use mlx5_timecounter_cyc2time instead which guarantees a safe access. Fixes: afc98a0b46d8 ("net/mlx5: Update ptp_clock_event foreach PPS event") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net/mlx5: Fix uninitialized variable warningMoshe Tal1-1/+1
[ Upstream commit 19f5b63bc9932d51292d72c9dc3ec95e5dfa2289 ] Add variable initialization to eliminate the warning "variable may be used uninitialized". Fixes: 5f29458b77d5 ("net/mlx5e: Support dump callback in TX reporter") Signed-off-by: Moshe Tal <moshet@mellanox.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: fix a double free and a memory leakTom Rix1-1/+3
[ Upstream commit 7e8453e35e406981d7c529ff8f804285bc894ba3 ] clang static analyzer reports this problem mac.c:6204:2: warning: Attempt to free released memory kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The channels pointer is allocated in ath11k_mac_setup_channels_rates() When it fails midway, it cleans up the memory it has already allocated. So the error handling needs to skip freeing the memory. There is a second problem. ath11k_mac_setup_channels_rates(), allocates 3 channels. err_free misses releasing ar->mac.sbands[NL80211_BAND_6GHZ].channels Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200906212625.17059-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29rtw88: don't treat NULL pointer as an arrayBrian Norris1-2/+3
[ Upstream commit 22b726cbdd09d9891ede8aa122a950d2d0ae5e09 ] I'm not a standards expert, but this really looks to be undefined behavior, when chip->dig_cck may be NULL. (And, we're trying to do a NULL check a few lines down, because some chip variants will use NULL.) Fixes: fc637a860a82 ("rtw88: 8723d: Set IG register for CCK rate") Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200821211716.1631556-1-briannorris@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mwifiex: Do not use GFP_KERNEL in atomic contextChristophe JAILLET1-1/+1
[ Upstream commit d2ab7f00f4321370a8ee14e5630d4349fdacc42e ] A possible call chain is as follow: mwifiex_sdio_interrupt (sdio.c) --> mwifiex_main_process (main.c) --> mwifiex_process_cmdresp (cmdevt.c) --> mwifiex_process_sta_cmdresp (sta_cmdresp.c) --> mwifiex_ret_802_11_scan (scan.c) --> mwifiex_parse_single_response_buf (scan.c) 'mwifiex_sdio_interrupt()' is an interrupt function. Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC. So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in 'mwifiex_parse_single_response_buf()'. Fixes: 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and cfg80211_get_bss API") or Fixes: 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200809092906.744621-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29brcmfmac: check ndev pointerTom Rix1-1/+1
[ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ] Clang static analysis reports this error brcmfmac/core.c:490:4: warning: Dereference of null pointer (*ifp)->ndev->stats.rx_errors++; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this block of code if (ret || !(*ifp) || !(*ifp)->ndev) { if (ret != -ENODATA && *ifp) (*ifp)->ndev->stats.rx_errors++; brcmu_pkt_buf_free_skb(skb); return -ENODATA; } (*ifp)->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 <trix@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802161804.6126-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath11k: Fix possible memleak in ath11k_qmi_init_serviceWang Yufen1-0/+1
[ Upstream commit 28f1632118818d9dccabf4c0fccfe49686742317 ] When qmi_add_lookup fail, we should destroy the workqueue Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1595237804-66297-1-git-send-email-wangyufen@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29wcn36xx: Fix reported 802.11n rx_highest rate wcn3660/wcn3680Bryan O'Donoghue1-1/+1
[ Upstream commit 3b9fb6791e7113679b1eb472e6ce1659e80f5797 ] Qualcomm's document "80-WL007-1 Rev. J" states that the highest rx rate for the WCN3660 and WCN3680 on MCS 7 is 150 Mbps not the 72 Mbps stated here. This patch fixes the data-rate declared in the 5GHz table. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802004824.1307124-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: Fix the size used in a 'dma_free_coherent()' call in an error ↵Christophe JAILLET1-1/+1
handling path [ Upstream commit 454530a9950b5a26d4998908249564cedfc4babc ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. Fixes: 1863008369ae ("ath10k: fix shadow register implementation for WCN3990") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Rakesh Pillai <pillair@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200802122227.678637-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb()Dan Carpenter1-0/+2
[ Upstream commit 2705cd7558e718a7240c64eb0afb2edad5f8c190 ] The value of "htc_hdr->endpoint_id" comes from skb->data so Smatch marks it as untrusted so we have to check it before using it as an array offset. This is similar to a bug that syzkaller found in commit e4ff08a4d727 ("ath9k: Fix use-after-free Write in ath9k_htc_rx_msg") so it is probably a real issue. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141253.GA457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath6kl: prevent potential array overflow in ath6kl_add_new_sta()Dan Carpenter1-0/+3
[ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ] The value for "aid" comes from skb->data so Smatch marks it as untrusted. If it's invalid then it can result in an out of bounds array access in ath6kl_add_new_sta(). Fixes: 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200813141315.GB457408@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29ath10k: provide survey info as accumulated dataVenkateswara Naralasetty1-1/+1
[ Upstream commit 720e5c03e5cb26d33d97f55192b791bb48478aa5 ] It is expected that the returned counters by .get_survey are monotonic increasing. But the data from ath10k gets reset to zero regularly. Channel active/busy time are then showing incorrect values (less than previous or sometimes zero) for the currently active channel during successive survey dump commands. example: $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 54995 ms channel busy time: 432 ms channel receive time: 0 ms channel transmit time: 59 ms ... $ iw dev wlan0 survey dump Survey data from wlan0 frequency: 5180 MHz [in use] channel active time: 32592 ms channel busy time: 254 ms channel receive time: 0 ms channel transmit time: 0 ms ... The correct way to handle this is to use the non-clearing WMI_BSS_SURVEY_REQ_TYPE_READ wmi_bss_survey_req_type. The firmware will then accumulate the survey data and handle wrap arounds. Tested-on: QCA9984 hw1.0 10.4-3.5.3-00057 Tested-on: QCA988X hw2.0 10.2.4-1.0-00047 Tested-on: QCA9888 hw2.0 10.4-3.9.0.2-00024 Tested-on: QCA4019 hw1.0 10.4-3.6-00140 Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information") Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org> Tested-by: Markus Theil <markus.theil@tu-ilmenau.de> Tested-by: John Deere <24601deerej@gmail.com> [sven@narfation.org: adjust commit message] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1592232686-28712-1-git-send-email-kvalo@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29net: ethernet: mtk-star-emac: select REGMAP_MMIOBartosz Golaszewski1-0/+1
[ Upstream commit 5403caf21648d739bf2b1266c33e34384c313379 ] The driver depends on mmio regmap API but doesn't select the appropriate Kconfig option. This fixes it. Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29r8169: fix operation under forced interrupt threadingHeiner Kallweit1-4/+4
[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ] For several network drivers it was reported that using __napi_schedule_irqoff() is unsafe with forced threading. One way to fix this is switching back to __napi_schedule, but then we lose the benefit of the irqoff version in general. As stated by Eric it doesn't make sense to make the minimal hard irq handlers in drivers using NAPI a thread. Therefore ensure that the hard irq handler is never thread-ified. Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff") Link: https://lkml.org/lkml/2020/10/18/19 Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/4d3ef84a-c812-5072-918a-22a6f6468310@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setupXie He1-0/+1
[ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ] This driver calls ether_setup to set up the network device. The ether_setup function would add the IFF_TX_SKB_SHARING flag to the device. This flag indicates that it is safe to transmit shared skbs to the device. However, this is not true. This driver may pad the frame (in eth_tx) before transmission, so the skb may be modified. Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared") Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC deviceXie He1-1/+9
[ Upstream commit 01c4ceae0a38a0bdbfea6896f41efcd985a9c064 ] The hdlc_rcv function is used as hdlc_packet_type.func to process any skb received in the kernel with skb->protocol == htons(ETH_P_HDLC). The purpose of this function is to provide second-stage processing for skbs not assigned a "real" L3 skb->protocol value in the first stage. This function assumes the device from which the skb is received is an HDLC device (a device created by this module). It assumes that netdev_priv(dev) returns a pointer to "struct hdlc_device". However, it is possible that some driver in the kernel (not necessarily in our control) submits a received skb with skb->protocol == htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would still be received by hdlc_rcv. This will cause problems. hdlc_rcv should be able to recognize and drop invalid skbs. It should first make sure "dev" is actually an HDLC device, before starting its processing. This patch adds this check to hdlc_rcv. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Xie He <xie.he.0141@gmail.com> Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29net: ftgmac100: Fix Aspeed ast2600 TX hang issueDylan Hung2-0/+13
[ Upstream commit 137d23cea1c044b2d4853ac71bc68126b25fdbb2 ] The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to hang when handling scatter-gather DMA. Disable the problematic feature by setting MAC register 0x58 bit28 and bit27. Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property") Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29ibmvnic: save changed mac address to adapter->mac_addrLijun Pan1-0/+5
[ Upstream commit d9b0e599b2b892422f1cbc5d2658049b895b2b58 ] After mac address change request completes successfully, the new mac address need to be saved to adapter->mac_addr as well as netdev->dev_addr. Otherwise, adapter->mac_addr still holds old data. Fixes: 62740e97881c ("net/ibmvnic: Update MAC address settings after adapter reset") Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20201020223919.46106-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 18:42:48 +0300