- 07 Apr, 2020 6 commits
-
-
Qiujun Huang authored
In ath9k_hif_usb_rx_cb interface number is assumed to be 0. usb_ifnum_to_if(urb->dev, 0) But it isn't always true. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com usb 2-1: new high-speed USB device number 2 using dummy_hcd usb 2-1: config 1 has an invalid interface number: 2 but max is 0 usb 2-1: config 1 has no interface number 0 usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0 Call Trace __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com Signed-off-by:
Qiujun Huang <hqjagain@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com
-
Qiujun Huang authored
Add barrier to accessing the stack array skb_pool. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000003d7c1505a2168418@google.com BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 Write of size 8 at addr ffff8881db309a28 by task swapper/1/0 Call Trace: ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline] ath9k_hif_usb_rx_cb+0xdf6/0xf70 drivers/net/wireless/ath/ath9k/hif_usb.c:666 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+d403396d4df67ad0bd5f@syzkaller.appspotmail.com Signed-off-by:
-
Qiujun Huang authored
Write out of slab bounds. We should check epid. The case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000006ac55b05a1c05d72@google.com BUG: KASAN: use-after-free in htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] BUG: KASAN: use-after-free in ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 Write of size 2 at addr ffff8881cea291f0 by task swapper/1/0 Call Trace: htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline] ath9k_htc_rx_msg+0xa25/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:443 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+b1c61e5f11be5782f192@syzkaller.appspotmail.com Signed-off-by:
-
Qiujun Huang authored
Free wmi later after cmd urb has been killed, as urb cb will access wmi. the case reported by syzbot: https://lore.kernel.org/linux-usb/0000000000000002fc05a1d61a68@google.com BUG: KASAN: use-after-free in ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 Read of size 1 at addr ffff8881cef1417c by task swapper/1/0 Call Trace: <IRQ> ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215 ath9k_htc_rx_msg+0x2da/0xaf0 drivers/net/wireless/ath/ath9k/htc_hst.c:459 ath9k_hif_usb_reg_in_cb+0x1ba/0x630 drivers/net/wireless/ath/ath9k/hif_usb.c:718 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 Reported-and-tested-by: syzbot+5d338854440137ea0fef@syzkaller.appspotmail.com Signed-off-by:
-
Qiujun Huang authored
The skb is consumed by htc_send_epid, so it needn't release again. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000590f6b05a1c05d15@google.com usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 usb 1-1: Service connection timeout for: 256 ================================================================== BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:134 [inline] BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:1042 [inline] BUG: KASAN: use-after-free in kfree_skb+0x32/0x3d0 net/core/skbuff.c:692 Read of size 4 at addr ffff8881d0957994 by task kworker/1:2/83 Call Trace: kfree_skb+0x32/0x3d0 net/core/skbuff.c:692 htc_connect_service.cold+0xa9/0x109 drivers/net/wireless/ath/ath9k/htc_hst.c:282 ath9k_wmi_connect+0xd2/0x1a0 drivers/net/wireless/ath/ath9k/wmi.c:265 ath9k_init_htc_services.constprop.0+0xb4/0x650 drivers/net/wireless/ath/ath9k/htc_drv_init.c:146 ath9k_htc_probe_device+0x25a/0x1d80 drivers/net/wireless/ath/ath9k/htc_drv_init.c:959 ath9k_htc_hw_init+0x31/0x60 drivers/net/wireless/ath/ath9k/htc_hst.c:501 ath9k_hif_usb_firmware_cb+0x26b/0x500 drivers/net/wireless/ath/ath9k/hif_usb.c:1187 request_firmware_work_func+0x126/0x242 drivers/base/firmware_loader/main.c:976 process_one_work+0x94b/0x1620 kernel/workqueue.c:2264 worker_thread+0x96/0xe20 kernel/workqueue.c:2410 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 83: kmem_cache_alloc_node+0xdc/0x330 mm/slub.c:2814 __alloc_skb+0xba/0x5a0 net/core/skbuff.c:198 alloc_skb include/linux/skbuff.h:1081 [inline] htc_connect_service+0x2cc/0x840 drivers/net/wireless/ath/ath9k/htc_hst.c:257 ath9k_wmi_connect+0xd2/0x1a0 drivers/net/wireless/ath/ath9k/wmi.c:265 ath9k_init_htc_services.constprop.0+0xb4/0x650 drivers/net/wireless/ath/ath9k/htc_drv_init.c:146 ath9k_htc_probe_device+0x25a/0x1d80 drivers/net/wireless/ath/ath9k/htc_drv_init.c:959 ath9k_htc_hw_init+0x31/0x60 drivers/net/wireless/ath/ath9k/htc_hst.c:501 ath9k_hif_usb_firmware_cb+0x26b/0x500 drivers/net/wireless/ath/ath9k/hif_usb.c:1187 request_firmware_work_func+0x126/0x242 drivers/base/firmware_loader/main.c:976 process_one_work+0x94b/0x1620 kernel/workqueue.c:2264 worker_thread+0x96/0xe20 kernel/workqueue.c:2410 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 0: kfree_skb+0x102/0x3d0 net/core/skbuff.c:690 ath9k_htc_txcompletion_cb+0x1f8/0x2b0 drivers/net/wireless/ath/ath9k/htc_hst.c:356 hif_usb_regout_cb+0x10b/0x1b0 drivers/net/wireless/ath/ath9k/hif_usb.c:90 __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 Reported-and-tested-by: syzbot+9505af1ae303dabdc646@syzkaller.appspotmail.com Signed-off-by:
-
Venkateswara Naralasetty authored
Currently sta airtime is updated without any lock in case of host based airtime calculation. Which may result in accessing the invalid sta pointer in case of continuous station connect/disconnect. This patch fix the kernel null pointer dereference by updating the station airtime with proper RCU lock in case of host based airtime calculation. Proceeding with the analysis of "ARM Kernel Panic". The APSS crash happened due to OOPS on CPU 0. Crash Signature : Unable to handle kernel NULL pointer dereference at virtual address 00000300 During the crash, PC points to "ieee80211_sta_register_airtime+0x1c/0x448 [mac80211]" LR points to "ath10k_txrx_tx_unref+0x17c/0x364 [ath10k_core]". The Backtrace obtained is as follows: [<bf880238>] (ieee80211_sta_register_airtime [mac80211]) from [<bf945a38>] (ath10k_txrx_tx_unref+0x17c/0x364 [ath10k_core]) [<bf945a38>] (ath10k_txrx_tx_unref [ath10k_core]) from [<bf9428e4>] (ath10k_htt_txrx_compl_task+0xa50/0xfc0 [ath10k_core]) [<bf9428e4>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<bf9b9bc8>] (ath10k_pci_napi_poll+0x50/0xf8 [ath10k_pci]) [<bf9b9bc8>] (ath10k_pci_napi_poll [ath10k_pci]) from [<c059e3b0>] (net_rx_action+0xac/0x160) [<c059e3b0>] (net_rx_action) from [<c02329a4>] (__do_softirq+0x104/0x294) [<c02329a4>] (__do_softirq) from [<c0232b64>] (run_ksoftirqd+0x30/0x90) [<c0232b64>] (run_ksoftirqd) from [<c024e358>] (smpboot_thread_fn+0x25c/0x274) [<c024e358>] (smpboot_thread_fn) from [<c02482fc>] (kthread+0xd8/0xec) Tested HW: QCA9888 Tested FW: 10.4-3.10-00047 Signed-off-by:
Venkateswara Naralasetty <vnaralas@codeaurora.org> Signed-off-by:
-
- 06 Apr, 2020 8 commits
-
-
Lei Wang authored
Enable radar detection in secondary segment for VHT160 and VHT80+80 mode on DFS channels. Otherwise, when injecting radar pulse in the secondary segment, the DUT can't detect radar pulse. Tested: qca9984 with firmware ver 10.4-3.10-00047 Signed-off-by:
Lei Wang <leiwa@codeaurora.org> Signed-off-by:
Sowmiya Sree Elavalagan <ssreeela@codeaurora.org> Signed-off-by:
-
Lei Wang authored
Set right channel frequencies in VHT160 mode according to the VHT160 interoperability workaround added as part of IEEE Std 802.11
™ -2016 in "Table 9-252—VHT Operation Information subfields", band_center_freq2 corresponds to CCFS1 in Table 9-253. Previous implementation (band_center_freq2 = 0 for VHT160) is only deprecated. Enable VHT80+80 mode and set the proper peer RX nss value for VHT160 and VHT80+80 mode. Based on patches by Sebastian Gottschall: https://lkml.kernel.org/r/20180704095444.662-1-s.gottschall@dd-wrt.com https://lkml.kernel.org/r/20180704120519.6479-1-s.gottschall@dd-wrt.com Tested: qca9984 with firmware ver 10.4-3.10-00047 Co-developed-by:Sebastian Gottschall <s.gottschall@dd-wrt.com> Signed-off-by:
Rick Wu <rwu@codeaurora.org> Signed-off-by:
-
Sriram R authored
The mgmt tx count reference is incremented/decremented on every mgmt tx and on tx completion event from firmware. In case of an unexpected mgmt tx completion event from firmware, the counter would underflow. Avoid this by decrementing only when the tx count is greater than 0. Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Sriram R authored
Increase the tx completion ring size to 0x8000.Also set the idr size to be same as the completion ring size. This avoids backpressure on the TX Completion and corresponding TCL Data ring during high data traffic. Signed-off-by:
-
Colin Ian King authored
Currently the error message refers to the command WMI_TWT_DIeABLE_CMDID which looks like a cut-n-paste mangled typo. Fix the message to match the command WMI_BSS_COLOR_CHANGE_ENABLE_CMDID that failed. Fixes: 5a032c8d ("ath11k: add WMI calls required for handling BSS color") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Maharaja Kennadyrajan authored
Pktlog data are different among the chipset & chipset versions. As part of enhancing the user space script to decode the pktlog trace events generated, it is desirable to know which chipset or which chipset version has provided the events and thereby decode the pktlogs appropriately. Pktlog checksum helps to determine the chipset variant which is given by the firmware in the struct wmi_ready_event. Pktlog checksums are computed during the firmware build. So, adding that pktlog checksum in the pklog trace events. Signed-off-by:
Maharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by:
-
Maharaja Kennadyrajan authored
There is a race condition, when the user writes 'hw-restart' and 'hard' in the simulate_fw_crash debugfs file without any delay. In the above scenario, the firmware dump work queue(scheduled by 'hard') should be handled gracefully, while the target is in the 'hw-restart'. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00044 Co-developed-by:
Govindaraj Saminathan <gsamin@codeaurora.org> Signed-off-by:
-
Maharaja Kennadyrajan authored
Add support to test aggregation procedures (addba/addba_resp/delba) manually by adding the required callbacks in sta debugfs files. To enable automatic aggregation in target, echo 0 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/ stations/XX:XX:XX:XX:XX:XX/aggr_mode For manual mode, echo 1 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/ stations/XX:XX:XX:XX:XX:XX/aggr_mode To send addba response, echo 0 25 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/ stations/XX:XX:XX:XX:XX:XX/addba_resp To send addba, echo 1 32 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/ stations/XX:XX:XX:XX:XX:XX/addba To send delba, echo 0 1 37 > /sys/kernel/debug/ieee80211/phyX/netdev:wlanX/ stations/XX:XX:XX:XX:XX:XX/delba Signed-off-by:
-
- 26 Mar, 2020 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.7. Major changes: ath11k * handle RX fragments * enable PN offload * add support for HE BSS color
-
Wright Feng authored
We add enable dynamic suspend (autosuspend) support in host driver, and it can let platform cut down idle power consumption. To support autosuspend feature in host driver, kernel need to be built with CONFIG_USB_SUSPEND and autosuspend need to be turn on. And we also replace wowl feature with adding "needs_remote_wakeup", so that host still can be waken by wireless device. Signed-off-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
-
Madhan Mohan R authored
Will enable FMAC to push more packets to bus tx queue and help improve throughput when fws queuing is enabled. This change is required to tune the throughput for passing WMM CERT tests. Signed-off-by:
Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by:
-
Raveendran Somu authored
The function brcmf_inform_single_bss returns the value as success, even when the length exceeds the maximum value. The fix is to send appropriate code on this error. This issue is observed when Cypress test group reported random fmac crashes when running their tests and the path was identified from the crash logs. With this fix the random failure issue in Cypress test group was resolved. Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Raveendran Somu <raveendran.somu@cypress.com> Signed-off-by:
-
Raveendran Somu authored
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 authored
When the control transfer gets timed out, the error status was returned without killing that urb, this leads to using the same urb. This issue causes the kernel crash as the same urb is sumbitted multiple times. The fix is to kill the urb for timeout transfer before returning error Signed-off-by:
-
Chris Chiu authored
The nl80211 commands such as 'iw link' can't get current txrate information from the driver. This commit fills in the tx rate information from the C2H RA report in the sta_statistics function. Signed-off-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
-
Chris Chiu authored
There's a data field in H2C and C2H commands which is used to carry channel bandwidth information. Add enumeration to make it more descriptive in code. Signed-off-by:
-
Yan-Hsuan Chuang authored
Sometimes we need to stop the coex mechanism to debug, so that we can manually control the device through various outer commands. Hence, add a new debugfs coex_enable to allow us to enable/disable the coex mechanism when driver is running. To disable coex echo 0 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable To enable coex echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable To check coex dm is enabled or not cat /sys/kernel/debug/ieee80211/phyX/rtw88/coex_enable Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
-
Yan-Hsuan Chuang authored
Add a new entry "coex_info" in debugfs to dump coex's states for us to debug on coex's issues. The basic concept for co-existence (coex, usually for WiFi + BT) is to decide a strategy based on the current status of WiFi and BT. So, it means the WiFi driver requires to gather information from BT side and choose a strategy (TDMA/table/HW settings). Althrough we can easily check the current status of WiFi, e.g., from kernel log or just dump the hardware registers, it is still very difficult for us to gather so many different types of WiFi states (such as RFE config, antenna, channel/band, TRX, Power save). Also we will need BT's information that is stored in "struct rtw_coex". So it is necessary for us to have a debugfs that can dump all of the WiFi/BT information required. Note that to debug on coex related issues, we usually need a longer period of time of coex_info dump every 2 seconds (for example, 30 secs, so we should have 15 times of coex_info's dump). Signed-off-by:
-
- 24 Mar, 2020 16 commits
-
-
Jakub Kicinski authored
We are having multiple review cycles with all vendors trying to implement devlink-info. Let's expand the documentation with more information about what's implemented and motivation behind this interface in an attempt to make the implementations easier. Describe what each info section is supposed to contain, and make some references to other HW interfaces (PCI caps). Document how firmware management is expected to look, to make it clear how devlink-info and devlink-flash work in concert. Name some future work. v2: - improve wording v3: - improve wording Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
It looks like the VSC8584 PHY driver is rolling its own RGMII delay configuration code, despite the fact that the logic is mostly the same. In fact only the register layout and position for the RGMII controls has changed. So we need to adapt and parameterize the PHY-dependent bit fields when calling the new generic function. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
David S. Miller authored
Andre Przywara says: ==================== net: axienet: Update error handling and add 64-bit DMA support a minor update, fixing the 32-bit build breakage, and brightening up Dave's christmas tree. Rebased against latest net-next/master. This series is based on net-next as of today (9970de8b), which includes Russell's fixes [1], solving the SGMII issues I have had. [1] https://lore.kernel.org/netdev/E1j6trA-0003GY-N1@rmk-PC.armlinux.org.uk/ Changelog v2 .. v3: - Use two "left-shifts by 16" to fix builds with 32-bit phys_addr_t - reorder variable declarations Changelog v1 .. v2: - Add Reviewed-by: tags from Radhey - Extend kerndoc documentation - Convert DMA error handler tasklet to work queue - log DMA mapping errors - mark DMA mapping error checks as unlikely (in "hot" paths) - return NETDEV_TX_OK on TX DMA mapping error (increasing TX drop counter) - Request eth IRQ as an optional IRQ - Remove no longer needed MDIO IRQ register names - Drop DT propery check for address width, assume full 64 bit This series updates the Xilinx Axienet driver to work on our board here. One big issue was broken SGMII support, which Russell fixed already (in net-next). While debugging and understanding the driver, I found several problems in the error handling and cleanup paths, which patches 2-7 address. Patch 8 removes a annoying error message, patch 9 paves the way for newer revisions of the IP. The next patch adds mii-tool support, just for good measure. The next four patches add support for 64-bit DMA. This is an integration option on newer IP revisions (>= v7.1), and expects MSB bits in formerly reserved registers. Without writing to those MSB registers, the state machine won't trigger, so it's mandatory to access them, even if they are zero. Patches 11 and 12 prepare the code by adding accessors, to wrap this properly and keep it working on older IP revisions. Patch 13 enables access to the MSB registers, by trying to write a non-zero value to them and checking if that sticks. Older IP revisions always read those registers as zero. Patch 14 then adjusts the DMA mask, based on the autodetected MSB feature. It uses the full 64 bits in this case, the rest of the system (actual physical addresses in use) should provide a natural limit if the chip has connected fewer address lines. If not, the parent DT node can use a dma-range property. The Xilinx PG138 and PG021 documents (in versions 7.1 in both cases) were used for this series. ==================== Signed-off-by:
-
Andre Przywara authored
With all DMA address accesses wrapped, we can actually support 64-bit DMA if this option was chosen at IP integration time. If the IP has been configured for an address width greater than 32 bits, we assume the full 64 bit DMA width is working. In practise this will be limited by the actual system address bus width, which will ideally be the same as the DMA IP address width. If this is not the case, the actual width can still be configured using a dma-ranges property in the parent of the MAC node. This increases the DMA mask on those systems to let the kernel choose buffers from memory at higher addresses. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
-
Andre Przywara authored
When newer revisions of the Axienet IP are configured for a 64-bit bus, we *need* to write to the MSB part of the an address registers, otherwise the IP won't recognise this as a DMA start condition. This is even true when the actual DMA address comes from the lower 4 GB. To autodetect this configuration, at probe time we write all 1's to such an MSB register, and see if any bits stick. If this is configured for a 32-bit bus, those MSB registers are RES0, so reading back 0 indicates that no MSB writes are necessary. On the other hands reading anything other than 0 indicated the need to write the MSB registers, so we set the respective flag. The actual DMA mask stays at 32-bit for now. To help bisecting, a separate patch will enable allocations from higher addresses. Signed-off-by:
-
Andre Przywara authored
Newer revisions of the AXI DMA IP (>= v7.1) support 64-bit addresses, both for the descriptors itself, as well as for the buffers they are pointing to. This is realised by adding "MSB" words for the next and phys pointer right behind the existing address word, now named "LSB". These MSB words live in formerly reserved areas of the descriptor. If the hardware supports it, write both words when setting an address. The buffer address is handled by two wrapper functions, the two occasions where we set the next pointers are open coded. For now this is guarded by a flag which we don't set yet. Signed-off-by:
-
Andre Przywara authored
Newer versions of the Xilink DMA IP support busses with more than 32 address bits, by introducing an MSB word for the registers holding DMA pointers (tail/current, RX/TX descriptor addresses). On IP configured for more than 32 bits, it is also *required* to write both words, to let the IP recognise this as a start condition for an MM2S request, for instance. Wrap the DMA pointer writes with a separate function, to add this functionality later. For now we stick to the lower 32 bits. Signed-off-by:
-
Andre Przywara authored
mii-tool is useful for debugging, and all it requires to work is to wire up the ioctl ops function pointer. Add this to the axienet driver to enable mii-tool. Signed-off-by:
-
Andre Przywara authored
Newer revisions of the IP don't have these registers. Since we don't really use them, just drop them from the ethtools dump. Signed-off-by:
-
Andre Przywara authored
According to the DT binding, the Ethernet core interrupt is optional. Use platform_get_irq_optional() to avoid the error message when the IRQ is not specified. Signed-off-by:
-
Andre Przywara authored
Especially with the default 32-bit DMA mask, DMA buffers are a limited resource, so their allocation can fail. So as the DMA API documentation requires, add error checking code after dma_map_single() calls to catch the case where we run out of "low" memory. Signed-off-by:
-
Andre Przywara authored
Factor out the code that cleans up a number of connected TX descriptors, as we will need it to properly roll back a failed _xmit() call. There are subtle differences between cleaning up a successfully sent chain (unknown number of involved descriptors, total data size needed) and a chain that was about to set up (number of descriptors known), so cater for those variations with some extra parameters. Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by:
-
Andre Przywara authored
Since 0 is a valid DMA address, we cannot use the physical address to check whether a TX descriptor is valid and is holding a DMA mapping. Use the "cntrl" member of the descriptor to make this decision, as it contains at least the length of the buffer, so 0 points to an uninitialised buffer. Signed-off-by:
-
Andre Przywara authored
When axienet_dma_bd_init() bails out during the initialisation process, it might do so with parts of the structure already allocated and initialised, while other parts have not been touched yet. Before returning in this case, we call axienet_dma_bd_release(), which does not take care of this corner case. This is most obvious by the first loop happily dereferencing lp->rx_bd_v, which we actually check to be non NULL *afterwards*. Make sure we only unmap or free already allocated structures, by: - directly returning with -ENOMEM if nothing has been allocated at all - checking for lp->rx_bd_v to be non-NULL *before* using it - only unmapping allocated DMA RX regions This avoids NULL pointer dereferences when initialisation fails. Signed-off-by:
-
Andre Przywara authored
When we fail allocating the DMA buffers in axienet_dma_bd_init(), we report this error, but carry on with initialisation nevertheless. This leads to a kernel panic when the driver later wants to send a packet, as it uses uninitialised data structures. Make the axienet_device_reset() routine return an error value, as it contains the DMA buffer initialisation. Make sure we propagate the error up the chain and eventually fail the driver initialisation, to avoid relying on non-initialised buffers. Signed-off-by:
-
Andre Przywara authored
The DMA error handler routine is currently a tasklet, scheduled to run after the DMA error IRQ was handled. However it needs to take the MDIO mutex, which is not allowed to do in a tasklet. A kernel (with debug options) complains consequently: [ 614.050361] net eth0: DMA Tx error 0x174019 [ 614.064002] net eth0: Current BD is at: 0x8f84aa0ce [ 614.080195] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 [ 614.109484] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 40, name: kworker/u4:4 [ 614.135428] 3 locks held by kworker/u4:4/40: [ 614.149075] #0: ffff000879863328 ((wq_completion)rpciod){....}, at: process_one_work+0x1f0/0x6a8 [ 614.177528] #1: ffff80001251bdf8 ((work_completion)(&task->u.tk_work)){....}, at: process_one_work+0x1f0/0x6a8 [ 614.209033] #2: ffff0008784e0110 (sk_lock-AF_INET-RPC){....}, at: tcp_sendmsg+0x24/0x58 [ 614.235429] CPU: 0 PID: 40 Comm: kworker/u4:4 Not tainted 5.6.0-rc3-00926-g4a165a9d5921 #26 [ 614.260854] Hardware name: ARM Test FPGA (DT) [ 614.274734] Workqueue: rpciod rpc_async_schedule [ 614.289022] Call trace: [ 614.296871] dump_backtrace+0x0/0x1a0 [ 614.308311] show_stack+0x14/0x20 [ 614.318751] dump_stack+0xbc/0x100 [ 614.329403] ___might_sleep+0xf0/0x140 [ 614.341018] __might_sleep+0x4c/0x80 [ 614.352201] __mutex_lock+0x5c/0x8a8 [ 614.363348] mutex_lock_nested+0x1c/0x28 [ 614.375654] axienet_dma_err_handler+0x38/0x388 [ 614.389999] tasklet_action_common.isra.15+0x160/0x1a8 [ 614.405894] tasklet_action+0x24/0x30 [ 614.417297] efi_header_end+0xe0/0x494 [ 614.429020] irq_exit+0xd0/0xd8 [ 614.439047] __handle_domain_irq+0x60/0xb0 [ 614.451877] gic_handle_irq+0xdc/0x2d0 [ 614.463486] el1_irq+0xcc/0x180 [ 614.473451] __tcp_transmit_skb+0x41c/0xb58 [ 614.486513] tcp_write_xmit+0x224/0x10a0 [ 614.498792] __tcp_push_pending_frames+0x38/0xc8 [ 614.513126] tcp_rcv_established+0x41c/0x820 [ 614.526301] tcp_v4_do_rcv+0x8c/0x218 [ 614.537784] __release_sock+0x5c/0x108 [ 614.549466] release_sock+0x34/0xa0 [ 614.560318] tcp_sendmsg+0x40/0x58 [ 614.571053] inet_sendmsg+0x40/0x68 [ 614.582061] sock_sendmsg+0x18/0x30 [ 614.593074] xs_sendpages+0x218/0x328 [ 614.604506] xs_tcp_send_request+0xa0/0x1b8 [ 614.617461] xprt_transmit+0xc8/0x4f0 [ 614.628943] call_transmit+0x8c/0xa0 [ 614.640028] __rpc_execute+0xbc/0x6f8 [ 614.651380] rpc_async_schedule+0x28/0x48 [ 614.663846] process_one_work+0x298/0x6a8 [ 614.676299] worker_thread+0x40/0x490 [ 614.687687] kthread+0x134/0x138 [ 614.697804] ret_from_fork+0x10/0x18 [ 614.717319] xilinx_axienet 7fe00000.ethernet eth0: Link is Down [ 615.748343] xilinx_axienet 7fe00000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Since tasklets are not really popular anymore anyway, lets convert this over to a work queue, which can sleep and thus can take the MDIO mutex. Signed-off-by:
-
