- 10 Sep, 2024 40 commits
-
-
Yang Li authored
Add a new HCI protocol HCI_UART_AML for the Amlogic Bluetooth controller. It works on the standard H4 protocol via a 4-wire UART interface, with baud rates up to 4 Mbps. The controller supports two types of commands: the TCI commands and the vendor command. The former is for initial setup including setting baud rates, downloading fw, starting chip and etc, while the latter is for dumping firmware versions and setting public address after firmware updates and normal startup. It was verified on board of T602 (S905X4 + W265S2). dmesg: .. [ 5.313450] Bluetooth: HCI UART protocol AML registered [ 6.506052] Bluetooth: hci0: fw_version: date = 42.28, number = 0xb2fd ... Co-developed-by:
Ye He <ye.he@amlogic.com> Signed-off-by:
Yang Li <yang.li@amlogic.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Yang Li authored
Add binding document for Amlogic Bluetooth chipsets attached over UART. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Alexander Hall authored
This patch fixes bluetooth support on the MediaTek MT7925 WiFi 7 + BT 5.3 M.2 chipset that I purchased from aliexpress (and which arrived today). The PCB states that it is an MT7925B22M. Device from /sys/kernel/debug/usb/devices: T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3604 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us High fidelity images I took of the chip itself for future reference: https://archive.org/details/MediaTek-MT7925B22M/ Webpage the chip was purchased from, note it is different from the images taken: https://web.archive.org/web/20240620021119/https://www.aliexpress. us/item/3256806821207897.html Signed-off-by:
Alexander Hall <bearodark@gmail.com> Signed-off-by:
-
Kiran authored
Add support for handling ISO RX and TX packets. Signed-off-by:
Kiran <kiran.k@intel.com> Signed-off-by:
-
Kiran K authored
Add a helper function hci_iso_hdr() to extract iso header from skb. Signed-off-by:
-
Alexander Dahl authored
Was slightly misleading before, because printed is pointer to fwnode, not to phy device, as placement in message suggested. Include header for dev_dbg() declaration while at it. Output before: [ +0.001247] mdio_bus f802c000.ethernet-ffffffff: registered phy 2612f00a fwnode at address 3 Output after: [ +0.001229] mdio_bus f802c000.ethernet-ffffffff: registered phy fwnode /ahb/apb/ethernet@f802c000/ethernet-phy@3 at address 3 Reviewed-by:Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Alexander Dahl <ada@thorsis.com> Link: https://patch.msgid.link/20240906062256.11289-1-ada@thorsis.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
D. Wythe authored
In commit 48b6190a ("net/smc: Limit SMC visits when handshake workqueue congested"), we introduce a mechanism to put constraint on SMC connections visit according to the pressure of SMC handshake process. At that time, we believed that controlling the feature through netlink was sufficient. However, most people have realized now that netlink is not convenient in container scenarios, and sysctl is a more suitable approach. In addition, since commit 462791bb ("net/smc: add sysctl interface for SMC") had introcuded smc_sysctl_net_init(), it is reasonable for us to initialize limit_smc_hs in it instead of initializing it in smc_pnet_net_int(). Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
Wen Gu <guwen@linux.alibaba.com> Reviewed-by:
Jan Karcher <jaka@linux.ibm.com> Link: https://patch.msgid.link/1725590135-5631-1-git-send-email-alibuda@linux.alibaba.comSigned-off-by:
-
Lee Trager authored
This adds support to show firmware version information for both stored and running firmware versions. The version and commit is displayed separately to aid monitoring tools which only care about the version. Example output: # devlink dev info pci/0000:01:00.0: driver fbnic serial_number 88-25-08-ff-ff-01-50-92 versions: running: fw 24.07.15-017 fw.commit h999784ae9df0 fw.bootloader 24.07.10-000 fw.bootloader.commit hfef3ac835ce7 stored: fw 24.07.24-002 fw.commit hc9d14a68b3f2 fw.bootloader 24.07.22-000 fw.bootloader.commit h922f8493eb96 fw.undi 01.00.03-000 Signed-off-by:Lee Trager <lee@trager.us> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20240905233820.1713043-1-lee@trager.usSigned-off-by:
-
Paolo Abeni authored
Daniel Machon says: ==================== net: lan966x: use the newly introduced FDMA library This patch series is the second of a 2-part series [1], that adds a new common FDMA library for Microchip switch chips Sparx5 and lan966x. These chips share the same FDMA engine, and as such will benefit from a common library with a common implementation. This also has the benefit of removing a lot of open-coded bookkeeping and duplicate code for the two drivers. In this second series, the FDMA library will be taken into use by the lan966x switch driver. ################### # Example of use: # ################### - Initialize the rx and tx fdma structs with values for: number of DCB's, number of DB's, channel ID, DB size (data buffer size), and total size of the requested memory. Also provide two callbacks: nextptr_cb() and dataptr_cb() for getting the nextptr and dataptr. - Allocate memory using fdma_alloc_phys() or fdma_alloc_coherent(). - Initialize the DCB's with fdma_dcb_init(). - Add new DCB's with fdma_dcb_add(). - Free memory with fdma_free_phys() or fdma_free_coherent(). ##################### # Patch breakdown: # ##################### Patch #1: select FDMA library for lan966x. Patch #2: includes the fdma_api.h header and removes old symbols. Patch #3: replaces old rx and tx variables with equivalent ones from the fdma struct. Only the variables that can be changed without breaking traffic is changed in this patch. Patch #4: uses the library for allocation of rx buffers. This requires quite a bit of refactoring in this single patch. Patch #5: uses the library for adding DCB's in the rx path. Patch #6: uses the library for freeing rx buffers. Patch #7: uses the library for allocation of tx buffers. This requires quite a bit of refactoring in this single patch. Patch #8: uses the library for adding DCB's in the tx path. Patch #9: uses the library helpers in the tx path. Patch #10: ditch last_in_use variable and use library instead. Patch #11: uses library helpers throughout. Patch #12: refactor lan966x_fdma_reload() function. [1] https://lore.kernel.org/netdev/20240902-fdma-sparx5-v1-0-1e7d5e5a9f34@microchip.com/Signed-off-by:Daniel Machon <daniel.machon@microchip.com> ==================== Link: https://patch.msgid.link/20240905-fdma-lan966x-v1-0-e083f8620165@microchip.comSigned-off-by:
-
Daniel Machon authored
Now that we store everything in the fdma structs, refactor lan966x_fdma_reload() to store and restore the entire struct. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Daniel Machon authored
The library provides helpers for a number of DCB and DB operations. Use these throughout the code and remove the old ones. Signed-off-by:
-
Daniel Machon authored
This variable is used in the tx path to determine the last used DCB. The library has the variable last_dcb for the exact same purpose. Ditch the last_in_use variable throughout. Signed-off-by:
-
Daniel Machon authored
The library has the helper fdma_free_phys() for freeing physical FDMA memory. Use it in the exit path. Signed-off-by:
-
Daniel Machon authored
Use the fdma_dcb_add() function to add DCB's in the tx path. This gets rid of the open-coding of nextptr and dataptr handling and leaves it to the library. Signed-off-by:
-
Daniel Machon authored
Use the two functions: fdma_alloc_phys() and fdma_dcb_init() for rx buffer allocation and use the new buffers throughout. In order to replace the old buffers with the new ones, we have to do the following refactoring: - use fdma_alloc_phys() and fdma_dcb_init() - replace the variables: tx->dma, tx->dcbs and tx->curr_entry with the equivalents from the FDMA struct. - add lan966x_fdma_tx_dataptr_cb callback for obtaining the dataptr. - Initialize FDMA struct values. Signed-off-by: -
Daniel Machon authored
The library has the helper fdma_free_phys() for freeing physical FDMA memory. Use it in the exit path. Signed-off-by:
-
Daniel Machon authored
Use the fdma_dcb_add() function to add DCB's in the rx path. This gets rid of the open-coding of nextptr and dataptr handling and the functions for adding DCB's. Signed-off-by:
-
Daniel Machon authored
Use the two functions: fdma_alloc_phys() and fdma_dcb_init() for rx buffer allocation and use the new buffers throughout. In order to replace the old buffers with the new ones, we have to do the following refactoring: - use fdma_alloc_phys() and fdma_dcb_init() - replace the variables: rx->dma, rx->dcbs and rx->last_entry with the equivalents from the FDMA struct. - make use of fdma->db_size for rx buffer size. - add lan966x_fdma_rx_dataptr_cb callback for obtaining the dataptr. - Initialize FDMA struct values. Signed-off-by: -
Daniel Machon authored
Replace the old rx and tx variables: channel_id, FDMA_DCB_MAX, FDMA_RX_DCB_MAX_DBS, FDMA_TX_DCB_MAX_DBS, dcb_index and db_index with the equivalents from the FDMA rx and tx structs. These variables are not entangled in any buffer allocation and can therefore be replaced in advance. Signed-off-by:
-
Daniel Machon authored
Include and use the new FDMA header, which now provides the required masks and bit offsets for operating on the DCB's and DB's. Signed-off-by:
-
Daniel Machon authored
Select the newly introduced FDMA library. Signed-off-by:
-
Jakub Kicinski authored
Brett Creeley says: ==================== ionic: convert Rx queue buffers to use page_pool Our home-grown buffer management needs to go away and we need to play nicely with the page_pool infrastructure. This patchset cleans up some of our API use and converts the Rx traffic queues to use page_pool. The first few patches are for tidying up things, then a small XDP configuration refactor, adding page_pool support, and finally adding support to hot swap an XDP program without having to reconfigure anything. The result is code that more closely follows current patterns, as well as a either a performance boost or equivalent performance as seen with iperf testing: mss netio tx_pps rx_pps total_pps tx_bw rx_bw total_bw ---- ------- ---------- ---------- ----------- ------- ------- ---------- Before: 256 bidir 13,839,293 15,515,227 29,354,520 34 38 71 512 bidir 13,913,249 14,671,693 28,584,942 62 65 127 1024 bidir 13,006,189 13,695,413 26,701,602 109 115 224 1448 bidir 12,489,905 12,791,734 25,281,639 145 149 294 2048 bidir 9,195,622 9,247,649 18,443,271 148 149 297 4096 bidir 5,149,716 5,247,917 10,397,633 160 163 323 8192 bidir 3,029,993 3,008,882 6,038,875 179 179 358 9000 bidir 2,789,358 2,800,744 5,590,102 181 180 361 After: 256 bidir 21,540,037 21,344,644 42,884,681 52 52 104 512 bidir 23,170,014 19,207,260 42,377,274 103 85 188 1024 bidir 17,934,280 17,819,247 35,753,527 150 149 299 1448 bidir 15,242,515 14,907,030 30,149,545 167 174 341 2048 bidir 10,692,542 10,663,023 21,355,565 177 176 353 4096 bidir 6,024,977 6,083,580 12,108,557 187 180 367 8192 bidir 3,090,449 3,048,266 6,138,715 180 176 356 9000 bidir 2,859,146 2,864,226 5,723,372 178 180 358 v2: https://lore.kernel.org/20240826184422.21895-1-brett.creeley@amd.com v1: https://lore.kernel.org/20240625165658.34598-1-shannon.nelson@amd.com ==================== Link: https://patch.msgid.link/20240906232623.39651-1-brett.creeley@amd.comSigned-off-by:
-
Brett Creeley authored
Using examples of other driver(s), add the ability to hot-swap an XDP program without having to reconfigure the queues. To prevent the q->xdp_prog to be read/written more than once use READ_ONCE() and WRITE_ONCE() on the q->xdp_prog. The q->xdp_prog was being checked in multiple different for loops in the hot path. The change to allow xdp_prog hot swapping created the possibility for many READ_ONCE(q->xdp_prog) calls during a single napi callback. Refactor the Rx napi handling to allow a previous READ_ONCE(q->xdp_prog) (or NULL for hwstamp_rxq) to be passed into the relevant functions. Also, move other Rx related hotpath handling into the newly created ionic_rx_cq_service() function to reduce the scope of the xdp_prog local variable and put all Rx handling in one function similar to Tx. Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Link: https://patch.msgid.link/20240906232623.39651-8-brett.creeley@amd.comSigned-off-by:
-
Shannon Nelson authored
Our home-grown buffer management needs to go away and we need to be playing nicely with the page_pool infrastructure. This converts the Rx traffic queues to use page_pool. Also, since ionic_rx_buf_size() was removed, redefine IONIC_PAGE_SIZE to account for IONIC_MAX_BUF_LEN being the largest allowed buffer to prevent overflowing u16 variables, which could happen when PAGE_SIZE is defined as >= 64KB. include/linux/minmax.h:93:37: warning: conversion from 'long unsigned int' to 'u16' {aka 'short unsigned int'} changes value from '65536' to '0' [-Woverflow] Signed-off-by: -
Brett Creeley authored
Currently when going to/from a NULL XDP program the driver uses ionic_stop_queues_reconfig() and then ionic_start_queues_reconfig() in order to re-register the xdp_rxq_info and re-init the queues. This is fine until page_pool(s) are used in an upcoming patch. In preparation for adding page_pool support make sure to completely rebuild the queues when going to/from a NULL XDP program. Without this change the call to mem_allocator_disconnect() never happens when going to a NULL XDP program, which eventually results in xdp_rxq_info_reg_mem_model() failing with -ENOSPC due to the mem_id_pool ida having no remaining space. Signed-off-by:
-
Shannon Nelson authored
Instead of setting up and tearing down the rxq_info only when the XDP program is loaded or unloaded, we will build the rxq_info whether or not XDP is in use. This is the more common use pattern and better supports future conversion to page_pool. Since the rxq_info wants the napi_id we re-order things slightly to tie this into the queue init and deinit functions where we do the add and delete of napi. Signed-off-by:
-
Shannon Nelson authored
We originally were using a per-interface xdp_prog variable to track a loaded XDP program since we knew there would never be support for a per-queue XDP program. With that, we only built the per queue rxq_info struct when an XDP program was loaded and removed it on XDP program unload, and used the pointer as an indicator in the Rx hotpath to know to how build the buffers. However, that's really not the model generally used, and makes a conversion to page_pool Rx buffer cacheing a little problematic. This patch converts the driver to use the more common approach of using a per-queue xdp_prog pointer to work out buffer allocations and need for bpf_prog_run_xdp(). We jostle a couple of fields in the queue struct in order to keep the new xdp_prog pointer in a warm cacheline. Signed-off-by:
-
Shannon Nelson authored
We aren't "putting" buf, we're just unlinking them from our tracking in order to let the XDP_TX and XDP_REDIRECT tx clean paths take care of the pages when they are done with them. This rename clears up the intent. Signed-off-by:
-
Shannon Nelson authored
Here's a little debugging aid in case the device starts throwing Tx completion errors. Signed-off-by:
-
Jakub Kicinski authored
Gal Pressman says: ==================== RX software timestamp for all - round 3 Rounds 1 & 2 of drivers conversion were merged [1][2], this round will complete the work. [1] https://lore.kernel.org/netdev/20240901112803.212753-1-gal@nvidia.com/ [2] https://lore.kernel.org/netdev/20240904074922.256275-1-gal@nvidia.com/ ==================== Link: https://patch.msgid.link/20240906144632.404651-1-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Carolina Jubran <cjubran@nvidia.com> Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by:
Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20240906144632.404651-17-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Richard Cochran <richardcochran@gmail.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20240906144632.404651-16-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Martin Habets <habetsm.xilinx@gmail.com> Link: https://patch.msgid.link/20240906144632.404651-14-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
