- 04 Oct, 2022 8 commits
-
-
Ping-Ke Shih authored
This efuse region is to store PHY calibration, and it is a separated region from the region that stores MAC address. Then, use these data to configure via chip_ops::power_trim that is a calibration mechanism of TX power. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-9-pkshih@realtek.com
-
Ping-Ke Shih authored
efuse stores individual data about a chip itself, such as MAC address, country code, RF and crystal calibration data, and so on. Define a struct to help access efuse content, and copy them into a common struct. Signed-off-by:
-
Ping-Ke Shih authored
This chip_ops is to set TX power according to country, channel, rate and so on. Since shared code is used to configure TX power, we only implement specific part in this patch. Signed-off-by:
-
Zong-Zhe Yang authored
Previously, value of each field is just shown as unsigned. Now, we start to show them with sign to make things more intuitive during debugging. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Previously, we thought control registers or setting things for TX power series may change according to chip. So, setting functions are implemented chip by chip. However, until now, the functions keep the same among chips, at least 8852A, 8852C, and 8852B. There is a sufficient number of chips to share generic setting functions. So, we now remake them including TX power by rate, TX power offset, TX power limit, and TX power limit RU as generic ones in phy.c. Besides, there are some code refinements in the generic ones, but almost all of the logic doesn't change. Signed-off-by:
-
Ping-Ke Shih authored
These tables are used by RFK to assist to configure PHY and RF registers. Signed-off-by:
-
Ping-Ke Shih authored
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALRF_029_00_014 (R32) - HALBB_027_046_05 Signed-off-by:
-
Ping-Ke Shih authored
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALRF_029_00_014 (R32) - HALBB_027_046_05 Signed-off-by:
-
- 30 Sep, 2022 32 commits
-
-
Jakub Kicinski authored
Merge tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.1 Few stack changes and lots of driver changes in this round. brcmfmac has more activity as usual and it gets new hardware support. ath11k improves WCN6750 support and also other smaller features. And of course changes all over. Note: in early September wireless tree was merged to wireless-next to avoid some conflicts with mac80211 patches, this shouldn't cause any problems but wanted to mention anyway. Major changes: mac80211 - refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO) feature continues brcmfmac - support CYW43439 SDIO chipset - support BCM4378 on Apple platforms - support CYW89459 PCIe chipset rtw89 - more work to get rtw8852c supported - P2P support - support for enabling and disabling MSDU aggregation via nl80211 mt76 - tx status reporting improvements ath11k - cold boot calibration support on WCN6750 - Target Wake Time (TWT) debugfs support for STA interface - support to connect to a non-transmit MBSSID AP profile - enable remain-on-channel support on WCN6750 - implement SRAM dump debugfs interface - enable threaded NAPI on all hardware - WoW support for WCN6750 - support to provide transmit power from firmware via nl80211 - support to get power save duration for each client - spectral scan support for 160 MHz wcn36xx - add SNR from a received frame as a source of system entropy * tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits) wifi: rtl8xxxu: Improve rtl8xxxu_queue_select wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM wifi: rtl8xxxu: gen2: Enable 40 MHz channel width wifi: rtw89: 8852b: configure DLE mem wifi: rtw89: check DLE FIFO size with reserved size wifi: rtw89: mac: correct register of report IMR wifi: rtw89: pci: set power cut closed for 8852be wifi: rtw89: pci: add to do PCI auto calibration wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf wifi: rtw89: add DMA busy checking bits to chip info wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels wifi: rtw89: pci: mask out unsupported TX channels iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper wifi: iwlwifi: Track scan_cmd allocation size explicitly brcmfmac: Remove the call to "dtim_assoc" IOVAR brcmfmac: increase dcmd maximum buffer size brcmfmac: Support 89459 pcie brcmfmac: increase default max WOWL patterns to 16 cw1200: fix incorrect check to determine if no element is found in list ... ==================== Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== mlx5 xsk updates part2 2022-09-28 XSK buffer improvements, This is part #2 of 4 parts series. 1) Expose xsk min chunk size to drivers, to allow the driver to adjust to a better buffer stride size 2) Adjust MTT page size to the XSK frame size, to avoid umem overrun in certain situations. 3) Use xsk frame size as the striding RQ page size for XSK RQs 4) KSM for unaligned XSK, KSM allows arbitrary buffer chunk lengths registration in HW, which makes more sense for unaligned XSK. 4) More cleanups and optimizations in preparation for next improvements in part3 part 1: https://lore.kernel.org/netdev/20220927203611.244301-1-saeed@kernel.org/ ==================== Link: https://lore.kernel.org/r/20220929072156.93299-1-saeed@kernel.orgSigned-off-by: -
Maxim Mikityanskiy authored
Although mlx5e_rq_free_shampo can be called unconditionally, it belongs to case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ. Move it there to allow to add more init/cleanup actions to the striding RQ case. If xdp_rxq_info_reg_mem_model fails, don't forget to destroy the page pool. Signed-off-by:
Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
Maxim Mikityanskiy authored
The same clear_bit is called in both error and success flows. Move the call to do it only once and remove the out label. Signed-off-by:
-
Maxim Mikityanskiy authored
To decrease the nesting level and reduce duplication of code, create functions to redirect direct RQTs to the actual RQs or drop_rq, which are used in the activation and deactivation flows of channels. Signed-off-by:
-
Maxim Mikityanskiy authored
mlx5e_xsk_page_alloc_pool became a thin wrapper around xsk_buff_alloc. Drop it and call xsk_buff_alloc directly. Signed-off-by:
-
Maxim Mikityanskiy authored
struct mlx5e_alloc_unit consists of a single union. Convert it to a union itself to simplify casting it to struct xdp_buff *, which will be used to implement XSK batching on striding RQ. Signed-off-by:
-
Maxim Mikityanskiy authored
mlx5e_alloc_unit stores the DMA address and a pointer to either struct page (regular RQ) or struct xdp_buff (XSK RQ). This DMA address is redundant, because when a page or an XSK frame is allocated, the same address is also stored there. Some flows take the address from struct mlx5e_alloc_unit, and some take it from struct page or xdp_buff. This commit removes the address from struct mlx5e_alloc_unit, which makes it twice as small and improves locality (this struct is used in an array), also saving on unnecessary stores to the addr field. Almost all flows know unambiguously whether the DMA address should be taken from page or from xdp_buff. The exception is the allocation flows, where a new branch appeared, which will be optimized out in the next commits. struct mlx5e_alloc_unit used to be called mlx5e_dma_info. Signed-off-by:
-
Maxim Mikityanskiy authored
The next commit will remove the DMA address from the struct currently called mlx5e_dma_info, because the same value can be retrieved with page_pool_get_dma_addr(page) in almost all cases, with the notable exception of SHAMPO (HW GRO implementation) that modifies this address on the fly, after the initial allocation. To keep the SHAMPO logic intact, struct mlx5e_dma_info remains in the SHAMPO code, consisting of addr and page (XSK is not compatible with SHAMPO). The struct used in all other places is renamed to mlx5e_alloc_unit, allowing the next commit to remove the addr field without affecting SHAMPO. The new name means "allocation unit", and it's more appropriate after the field with the DMA address gets removed. Signed-off-by:
-
Maxim Mikityanskiy authored
RX page cache stores dma_info structs, that consist of a pointer to struct page and a DMA address. In fact, the DMA address is extracted from struct page using page_pool_get_dma_addr when a page is pushed to the cache. By moving this call to the point when a page is popped from the cache, we can avoid storing the DMA address in the cache, effectively reducing its size by two times without losing any functionality. Signed-off-by:
-
Maxim Mikityanskiy authored
WQEs must not cross page boundaries, they are padded with NOPs if they don't fit the page. mlx5e_mpwrq_total_umr_wqebbs doesn't take into account this padding, risking reserving not enough space. The padding is not straightforward to add to this calculation, because WQEs of different sizes may be mixed together in the queue. If each page ends with a big WQE that doesn't fit and requires at most its size minus 1 WQEBB of padding, the total space can be much bigger than in case when smaller WQEs take advantage of this padding. Replace the wrong exact calculation by the following estimation. Each padding can be at most the size of the maximum WQE used in the queue minus one WQEBB. Let's call the rest of the page "useful space". If we divide the total size of all needed WQEs by this useful space, rounding up, we'll get the number of pages, which is enough to contain all these WQEs. It's correct, because every WQE that appeared on the boundary between two blocks of useful space would start in the useful space of one page and end in the padding of the same page, while our estimation reserved space for its tail in the next space, making the estimation not smaller than the real space occupied in the queue. The code actually uses a looser estimation: instead of taking the maximum size of all used WQE types minus 1 WQEBB, it takes the maximum hardware size of a WQE. It's made for simplicity and extensibility. Signed-off-by:
-
Maxim Mikityanskiy authored
The previous commit removed the last usage of xsk_buff_discard in mlx5e, so the function that is no longer used can be removed. Signed-off-by:
-
Maxim Mikityanskiy authored
UMR MTTs used in striding RQ have certain alignment requirements. While it's guaranteed to work when UMR pages are aligned to the UMR page size, in practice it works then UMR pages are aligned to 8 bytes. However, it's still not enough flexibility for the unaligned mode of XSK. This patch leverages KSM to map UMR pages without alignment requirements, when unaligned XSK is active. The downside is that KSM entries are twice as big as MTTs, which limits the maximum WQE size, so regular RQs and aligned XSK continue using MTTs. Signed-off-by:
-
Maxim Mikityanskiy authored
Some commands use a flexible array after a common header. Add a macro to safely calculate the total input length of the command, detecting overflows and printing errors with specific values when such overflows happen. Signed-off-by:
-
Maxim Mikityanskiy authored
Currently, rq->mkey_be keeps a big-endian value of either the PA MKey (for legacy RQ, no address translation) or MTT MKey (for striding RQ, direct address translation). Striding RQ stores the same value in rq->umr_mkey in the native endianness. The next commit will make striding RQ use KSM MKey (indirect address translation) for the unaligned mode of XSK, which will require storing both KSM MKey and PA MKey in the RQ struct. This commit optimizes fields of mlx5e_rq: umr_mkey is removed (it's redundant), mkey_be always points to the PA MKey, and mpwqe.umr_mkey_be points to the MTT MKey (or to the KSM MKey, starting from the next commit). Signed-off-by:
-
Maxim Mikityanskiy authored
XSK RQs support striding RQ linear mode, but the stride size is always set to PAGE_SIZE. It may be larger than the XSK frame size, unnecessarily reducing the useful space in a WQE, but more importantly causing UMEM data corruption in certain cases. Normally, stride size bigger than XSK frame size is not a problem if the hardware enforces the MTU. However, traffic between vports skips the hardware MTU check, and oversized packets may be received. If an oversized packet is bigger than the XSK frame but not bigger than the stride, it will cause overwriting of the adjacent UMEM region. If the packet takes more than one stride, they can be recycled for reuse so it's not a problem when the XSK frame size matches the stride size. To reduce the impact of the above issue, attempt to use the MTT page size for striding RQ that matches the XSK frame size, allowing to safely use 2048-byte frames on an up-to-date firmware. Signed-off-by:
-
Maxim Mikityanskiy authored
This commit allows striding RQ to determine MTT page size at runtime, instead of sticking to the compile-time PAGE_SIZE. This functionality will be used by a following commit that adjusts the MTT page size to the XSK frame size. Stick with PAGE_SIZE for XSK on legacy RQ, as frag_stride is not used in data path, it only helps calculate how pages are partitioned into fragments, and PAGE_SIZE will ensure each fragment starts at the beginning of a new allocation unit (XSK frame). Signed-off-by:
-
Maxim Mikityanskiy authored
Drivers should be aware of the range of valid UMEM chunk sizes to be able to allocate their internal structures of an appropriate size. It will be used by mlx5e in the following patches. Signed-off-by:
-
Hongbin Wang authored
There should be no space before the comma Signed-off-by:
Hongbin Wang <wh_bin@126.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jianguo Zhang says: ==================== Mediatek ethernet patches for mt8188 Changes in v7: v7: 1) Add 'Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>' info in commit message of patch 'dt-bindings: net: snps,dwmac: add new property snps,clk-csr', 'arm64: dts: mediatek: mt2712e: Update the name of property 'clk_csr'' and 'net: stmmac: add a parse for new property 'snps,clk-csr''. v6: 1) Update commit message of patch 'dt-bindings: net: snps,dwmac: add new property snps,clk-csr' 2) Add a parse for new property 'snps,clk-csr' in patch 'net: stmmac: add a parse for new property 'snps,clk-csr'' v5: 1) Rename the property 'clk_csr' as 'snps,clk-csr' in binding file as Krzysztof Kozlowski'comment. 2) Add DTS patch 'arm64: dts: mediatek: mt2712e: Update the name of property 'clk_csr'' as Krzysztof Kozlowski'comment. 3) Add driver patch 'net: stmmac: Update the name of property 'clk_csr'' as Krzysztof Kozlowski'comment. v4: 1) Update the commit message of patch 'dt-bindings: net: snps,dwmac: add clk_csr property' as Krzysztof Kozlowski'comment. v3: 1) List the names of SoCs mt8188 and mt8195 in correct order as AngeloGioacchino Del Regno's comment. 2) Add patch version info as Krzysztof Kozlowski'comment. v2: 1) Delete patch 'stmmac: dwmac-mediatek: add support for mt8188' as Krzysztof Kozlowski's comment. 2) Update patch 'dt-bindings: net: mediatek-dwmac: add support for mt8188' as Krzysztof Kozlowski's comment. 3) Add clk_csr property to fix warning ('clk_csr' was unexpected) when runnig 'make dtbs_check'. v1: 1) Add ethernet driver entry for mt8188. 2) Add binding document for ethernet on mt8188. ==================== Signed-off-by: -
Jianguo Zhang authored
Parse new property 'snps,clk-csr' firstly because the new property is documented in binding file, if failed, fall back to old property 'clk_csr' for legacy case Signed-off-by:
Jianguo Zhang <jianguo.zhang@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Jianguo Zhang authored
Update the name of property 'clk_csr' as 'snps,clk-csr' to align with the property name in the binding file. Signed-off-by:
-
Jianguo Zhang authored
Add description for new property snps,clk-csr in binding file Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Jianguo Zhang authored
Add binding document for the ethernet on mt8188 Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a devlink_health_report message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a literal string in the array bnad_net_stats_strings. Fix it. Signed-off-by:
-
Nick Child authored
Implement channel management functions to allow dynamic addition and removal of transmit queues. The `ethtool --show-channels` and `ethtool --set-channels` commands can be used to get and set the number of queues, respectively. Allow the ability to add as many transmit queues as available processors but never allow more than the hard maximum of 16. The number of receive queues is one and cannot be modified. Depending on whether the requested number of queues is larger or smaller than the current value, either allocate or free long term buffers. Since long term buffer construction and destruction can occur in two different areas, from either channel set requests or device open/close, define functions for performing this work. If allocation of a new buffer fails, then attempt to revert back to the previous number of queues. Signed-off-by:
Nick Child <nnac123@linux.ibm.com> Signed-off-by:
-
Nick Child authored
The `ndo_start_xmit` function is protected by a spinlock on the tx queue being used to transmit the skb. Allow concurrent calls to `ndo_start_xmit` by using more than one tx queue. This allows for greater throughput when several jobs are trying to transmit data. Introduce 16 tx queues (leave single rx queue as is) which each correspond to one DMA mapped long term buffer. Signed-off-by:
-
Nick Child authored
Rather than DMA mapping and unmapping every outgoing skb, copy the skb into a buffer that was mapped during the drivers open function. Copying the skb and its frags have proven to be more time efficient than mapping and unmapping. As an effect, performance increases by 3-5 Gbits/s. Allocate and DMA map one continuous 64KB buffer at `ndo_open`. This buffer is maintained until `ibmveth_close` is called. This buffer is large enough to hold the largest possible linnear skb. During `ndo_start_xmit`, copy the skb and all of it's frags into the continuous buffer. By manually linnearizing all the socket buffers, time is saved during memcpy as well as more efficient handling in FW. As a result, we no longer need to worry about the firmware limitation of handling a max of 6 frags. So, we only need to maintain 1 descriptor instead of 6 and can hardcode 0 for the other 5 descriptors during h_send_logical_lan. Since, DMA allocation/mapping issues can no longer arise in xmit functions, we can further reduce code size by removing the need for a bounce buffer on DMA errors. Signed-off-by:
-
Colin Ian King authored
There are spelling mistakes in two literal strings. Fix these. Signed-off-by:
-
Steven Hsieh authored
As 2.5G, 5G ethernet ports are more common and affordable, these ports are being used in LAN bridge devices. STP port_cost() is missing path_cost assignment for these link speeds, causes highest cost 100 being used. This result in lower speed port being picked when there is loop between 5G and 1G ports. Original path_cost: 10G=2, 1G=4, 100m=19, 10m=100 Adjusted path_cost: 10G=2, 5G=3, 2.5G=4, 1G=5, 100m=19, 10m=100 speed greater than 10G = 1 Signed-off-by:Steven Hsieh <steven.hsieh@broadcom.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a netdev_err message. Fix it. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
