- 11 Feb, 2021 40 commits
-
-
git://git.kernel.org/pub/scm/linux/kernDavid S. Miller authored
el/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2021-02-11 Here's the main bluetooth-next pull request for 5.12: - Add support for advertising monitor offliading using Microsoft vendor extensions - Add firmware download support for MediaTek MT7921U USB devices - Suspend-related fixes for Qualcomm devices - Add support for Intel GarfieldPeak controller - Various other smaller fixes & cleanups Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Geetha sowjanya says: ==================== Add Marvell CN10K support The current admin function (AF) driver and the netdev driver supports OcteonTx2 silicon variants. The same OcteonTx2's Resource Virtualization Unit (RVU) is carried forward to the next-gen silicon ie OcteonTx3, with some changes and feature enhancements. This patch set adds support for OcteonTx3 (CN10K) silicon and gets the drivers to the same level as OcteonTx2. No new OcteonTx3 specific features are added. Changes cover below HW level differences - PCIe BAR address changes wrt shared mailbox memory region - Receive buffer freeing to HW - Transmit packet's descriptor submission to HW - Programmable HW interface identifiers (channels) - Increased MTU support - A Serdes MAC block (RPM) configuration v5-v6 Rebased on top of latest net-next branch. v4-v5 Fixed sparse warnings. v3-v4 Fixed compiler warnings. v2-v3 Reposting as a single thread. Rebased on top latest net-next branch. v1-v2 Fixed check-patch reported issues. ==================== Signed-off-by: -
Hariprasad Kelam authored
MAC on CN10K silicon support loopback for selftest or debug purposes. This patch does necessary configuration to loopback packets upon receiving request from LMAC mapped RVU PF's netdev via mailbox. Also MAC (CGX) on OcteonTx2 silicon variants and MAC (RPM) on OcteonTx3 CN10K are different and loopback needs to be configured differently. Upper layer interface between RVU AF and PF netdev is kept same. Based on silicon variant appropriate fn() pointer is called to config the MAC. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Hariprasad Kelam authored
RPM supports below list of counters as an extension to existing counters * class based flow control pause frames * vlan/jabber/fragmented packets * fcs/alignment/oversized error packets This patch adds support to display supported RPM counters via debugfs and define new mbox rpm_stats to read all support counters. Signed-off-by:
Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com> Signed-off-by:
-
Rakesh Babu authored
Flow control configuration is different for CGX(Octeontx2) and RPM(CN10K) functional blocks. This patch adds the necessary changes for RPM to support 802.3 pause frames configuration on cn10k platforms. Signed-off-by:
Rakesh Babu <rsaladi2@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
CN10K supports max MTU of 16K on LMAC links and 64k on LBK links and Octeontx2 silicon supports 9K mtu on both links. Get the same from nix_get_hw_info mbox message in netdev probe. This patch also calculates receive buffer size required based on the MTU set. Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx3 CN10K silicon supports bigger MTU when compared to 9216 MTU supported by OcteonTx2 silicon variants. Lookback interface supports upto 64K and RPM LMAC interfaces support upto 16K. This patch does the necessary configuration and adds support for PF/VF drivers to retrieve max packet size supported via mbox This patch also configures tx link credit by considering supported fifo size and max packet length for Octeontx3 silicon. This patch also removes platform specific name from the driver name. Signed-off-by:
-
Subbaraya Sundeep authored
NIX uses unique channel numbers to identify the packet sources/sinks like CGX,LBK and SDP. The channel numbers assigned to each block are hardwired in CN9xxx silicon. The fixed channel numbers in CN9xxx are: 0x0 | a << 8 | b - LBK(0..3)_CH(0..63) 0x0 | a << 8 - Reserved 0x700 | a - SDP_CH(0..255) 0x800 | a << 8 | b << 4 | c - CGX(0..7)_LMAC(0..3)_CH(0..15) All the channels in the above fixed enumerator(with maximum number of blocks) are not required since some chips have less number of blocks. For CN10K silicon the channel numbers need to be programmed by software in each block with the base channel number and range of channels. This patch calculates and assigns the channel numbers to efficiently distribute the channel number range(0-4095) among all the blocks. The assignment is made based on the actual number of blocks present and also contiguously leaving no holes. The channel numbers remaining after the math are used as new CPT replay channels present in CN10K. Also since channel numbers are not fixed the transmit channel link number needed by AF consumers is calculated by AF and sent along with nix_lf_alloc mailbox response. Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx2's next gen platform the CN10K has RPM MAC which has a different serdes when compared to CGX MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with CGX MAC, with few exceptions though. So we are using the same CGX driver for RPM MAC as well and will have a different set of APIs for RPM where ever necessary. This patch adds initial support for CN10K's RPM MAC i.e. the driver registration, communication with firmware etc. For communication with firmware, RPM provides a different IRQ when compared to CGX. The CGX and RPM blocks support different features. Currently few features like ptp, flowcontrol and higig are not supported by RPM. This patch adds new mailbox message "CGX_FEATURES_GET" to get the list of features supported by underlying MAC. RPM has different implementations for RX/TX stats. Unlike CGX, bar offset of stat registers are different. This patch adds support to access the same and dump the values in debugfs. Signed-off-by:
-
Geetha sowjanya authored
This patch adds support to use new LMTST lines for NPA batch free and burst SQE flush. Adds new dev_hw_ops structure to hold platform specific functions and create new files cn10k.c and cn10k.h. Signed-off-by:
-
Geetha sowjanya authored
On CN10K platform transmit/receive buffer alloc and free from/to hardware had changed to support burst operation. Whereas pervious silicon's only support single buffer free at a time. To Support the same firmware allocates a DRAM region for each PF/VF for storing LMTLINES. These LMTLINES are used for NPA batch free and for flushing SQE to the hardware. PF/VF LMTST region is accessed via BAR4. PFs LMTST region is followed by its VFs mbox memory. The size of region varies from 2KB to 256KB based on number of LMTLINES configured. This patch adds support for - Mapping PF/VF LMTST region. - Reserves 0-71 (RX + TX + XDP) LMTST lines for NPA batch free operation. - Reserves 72-512 LMTST lines for NIX SQE flush. Signed-off-by:
-
Geetha sowjanya authored
On CN10K platform NIX RQ and SQ context structure got changed. This patch uses new mbox message "NIX_CN10K_AQ_ENQ" for NIX context initialization on CN10K platform. This patch also updates the nix_rx_parse_s and nix_sqe_sg_s structures to add packet steering bit feilds. Signed-off-by:
-
Geetha sowjanya authored
On CN10K platform NPA and NIX context structure bit fields had changed to support new features like bandwidth steering etc. This patch dumps approprate context for CN10K platform. Signed-off-by:
-
Geetha sowjanya authored
NIX hardware context structure got changed to accommodate new features like bandwidth steering, L3/L4 outer/inner checksum enable/disable etc., on CN10K platform. This patch defines new mbox message NIX_CN10K_AQ_INST for new NIX context initialization. This patch also updates the NPA context structures to accommodate bit field changes made for CN10K platform. This patch also removes Big endian bit fields from existing structures as its support got deprecated in current and upcoming silicons. Signed-off-by:
-
Subbaraya Sundeep authored
Firmware allocates memory regions for PFs and VFs in DRAM. The PFs memory region is used for AF-PF and PF-VF mailbox. This mbox facilitate communication between AF-PF and PF-VF. On CN10K platform: The DRAM region allocated to PF is enumerated as PF BAR4 memory. PF BAR4 contains AF-PF mbox region followed by its VFs mbox region. AF-PF mbox region base address is configured at RVU_AF_PFX_BAR4_ADDR PF-VF mailbox base address is configured at RVU_PF(x)_VF_MBOX_ADDR = RVU_AF_PF()_BAR4_ADDR+64KB. PF access its mbox region via BAR4, whereas VF accesses PF-VF DRAM mailboxes via BAR2 indirect access. On CN9XX platform: Mailbox region in DRAM is divided into two parts AF-PF mbox region and PF-VF mbox region i.e all PFs mbox region is contiguous similarly all VFs. The base address of the AF-PF mbox region is configured at RVU_AF_PF_BAR4_ADDR. AF-PF1 mbox address can be calculated as RVU_AF_PF_BAR4_ADDR * mbox size. The base address of PF-VF mbox region for each PF is configure at RVU_AF_PF(0..15)_VF_BAR4_ADDR.PF access its mbox region via BAR4 and its VF mbox regions from RVU_PF_VF_BAR4_ADDR register, whereas VF access its mbox region via BAR4. This patch changes mbox initialization to support both CN9XX and CN10K platform. The patch also adds new hw_cap flag to setting hw features like TSO etc and removes platform specific name from the PF/VF driver name to make it appropriate for all supported platforms This patch also removes platform specific name from the PF/VF driver name to make it appropriate for all supported platforms Signed-off-by:
-
Subbaraya Sundeep authored
Firmware allocates memory regions for PFs and VFs in DRAM. The PFs memory region is used for AF-PF and PF-VF mailbox. This mbox facilitates communication between AF-PF and PF-VF. On CN10K platform: The DRAM region allocated to PF is enumerated as PF BAR4 memory. PF BAR4 contains AF-PF mbox region followed by its VFs mbox region. AF-PF mbox region base address is configured at RVU_AF_PFX_BAR4_ADDR PF-VF mailbox base address is configured at RVU_PF(x)_VF_MBOX_ADDR = RVU_AF_PF()_BAR4_ADDR+64KB. PF access its mbox region via BAR4, whereas VF accesses PF-VF DRAM mailboxes via BAR2 indirect access. On CN9XX platform: Mailbox region in DRAM is divided into two parts AF-PF mbox region and PF-VF mbox region i.e all PFs mbox region is contiguous similarly all VFs. The base address of the AF-PF mbox region is configured at RVU_AF_PF_BAR4_ADDR. AF-PF1 mbox address can be calculated as RVU_AF_PF_BAR4_ADDR * mbox size. The base address of PF-VF mbox region for each PF is configure at RVU_AF_PF(0..15)_VF_BAR4_ADDR.PF access its mbox region via BAR4 and its VF mbox regions from RVU_PF_VF_BAR4_ADDR register, whereas VF access its mbox region via BAR4. This patch changes mbox initialization to support both CN9XX and CN10K platform. This patch also adds CN10K PTP subsystem and device IDs to ptp driver id table. Signed-off-by:
-
David S. Miller authored
Stefan Chulski says: ==================== net: mvpp2: Add TX Flow Control support Armada hardware has a pause generation mechanism in GOP (MAC). The GOP generate flow control frames based on an indication programmed in Ports Control 0 Register. There is a bit per port. However assertion of the PortX Pause bits in the ports control 0 register only sends a one time pause. To complement the function the GOP has a mechanism to periodically send pause control messages based on periodic counters. This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause is asserted. Problem is that Packet Processor that actually can drop packets due to lack of resources not connected to the GOP flow control generation mechanism. To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow Control support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing to Ports Control 0 Register. MSS shared SRAM memory used to communicate between CM3 firmware and PP2 driver. During init PP2 driver informs firmware about used BM pools, RXQs, congestion and depletion thresholds. The pause frames are generated whenever congestion or depletion in resources is detected. The back pressure is stopped when the resource reaches a sufficient level. So the congestion/depletion and sufficient level implement a hysteresis that reduces the XON/XOFF toggle frequency. Packet Processor v23 hardware introduces support for RX FIFO fill level monitor. Patch "add PPv23 version definition" to differ between v23 and v22 hardware. Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow Control monitoring. v12 --> v13 - Remove bm_underrun_protect module_param v11 --> v12 - Improve warning message in "net: mvpp2: add TX FC firmware check" patch v10 --> v11 - Improve "net: mvpp2: add CM3 SRAM memory map" comment - Move condition check to 'net: mvpp2: always compare hw-version vs MVPP21' patch v9 --> v10 - Add CM3 SRAM description to PPv2 documentation v8 --> v9 - Replace generic pool allocation with devm_ioremap_resource v7 --> v8 - Reorder "always compare hw-version vs MVPP21" and "add PPv23 version definition" commits - Typo fixes - Remove condition fix from "add RXQ flow control configurations" v6 --> v7 - Reduce patch set from 18 to 15 patches - Documentation change combined into a single patch - RXQ and BM size change combined into a single patch - Ring size change check moved into "add RXQ flow control configurations" commit v5 --> v6 - No change v4 --> v5 - Add missed Signed-off - Fix warnings in patches 3 and 12 - Add revision requirement to warning message - Move mss_spinlock into RXQ flow control configurations patch - Improve FCA RXQ non occupied descriptor threshold commit message v3 --> v4 - Remove RFC tag v2 --> v3 - Remove inline functions - Add PPv2.3 description into marvell-pp2.txt - Improve mvpp2_interrupts_mask/unmask procedure - Improve FC enable/disable procedure - Add priv->sram_pool check - Remove gen_pool_destroy call - Reduce Flow Control timer to x100 faster v1 --> v2 - Add memory requirements information - Add EPROBE_DEFER if of_gen_pool_get return NULL - Move Flow control configuration to mvpp2_mac_link_up callback ==================== Signed-off-by: -
Stefan Chulski authored
Patch check that TX FC firmware is running in CM3. If not, global TX FC would be disabled. Signed-off-by:
Stefan Chulski <stefanc@marvell.com> Acked-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
-
Stefan Chulski authored
This patch fix GMAC TX flow control autoneg. Flow control autoneg wrongly were disabled with enabled TX flow control. Signed-off-by:
-
Stefan Chulski authored
New FIFO flow control feature was added in PPv23. PPv2 FIFO polled by HW and trigger pause frame if FIFO fill level is below threshold. FIFO HW flow control enabled with CM3 RXQ&BM flow control with ethtool. Current FIFO thresholds is: 9KB for port with maximum speed 10Gb/s port 4KB for port with maximum speed 5Gb/s port 2KB for port with maximum speed 1Gb/s port Signed-off-by:
-
Stefan Chulski authored
The PP2v23 hardware supports a feature allowing to double the size of BPPI by decreasing number of pools from 16 to 8. Increasing of BPPI size protect BM drop from BPPI underrun. Underrun could occurred due to stress on DDR and as result slow buffer transition from BPPE to BPPI. New BPPI threshold recommended by spec is: BPPI low threshold - 640 buffers BPPI high threshold - 832 buffers Supported only in PPv23. Signed-off-by:
-
Stefan Chulski authored
This patch add ethtool flow control configuration support. Tx flow control retrieved correctly by ethtool get function. FW per port ethtool configuration capability added. Patch also takes care about mtu change procedure, if PPv2 switch BM pools during mtu change. Signed-off-by:
-
Stefan Chulski authored
This patch adds RXQ flow control configurations. Flow control disabled by default. Minimum ring size limited to 1024 descriptors. Signed-off-by:
-
Stefan Chulski authored
This patch enables global flow control in FW and in the phylink validate mask. Signed-off-by:
-
Stefan Chulski authored
The firmware needs to monitor the RX Non-occupied descriptor bits for flow control to move to XOFF mode. These bits need to be unmasked to be functional, but they will not raise interrupts as we leave the RX exception summary bit in MVPP2_ISR_RX_TX_MASK_REG clear. Signed-off-by:
-
Stefan Chulski authored
Flow Control periodic timer would be used if port in XOFF to transmit periodic XOFF frames. Signed-off-by:
-
Stefan Chulski authored
BM pool and RXQ size increased to support Firmware Flow Control. Minimum depletion thresholds to support FC are 1024 buffers. BM pool size increased to 2048 to have some 1024 buffers space between depletion thresholds and BM pool size. Jumbo frames require a 9888B buffer, so memory requirements for data buffers increased from 7MB to 24MB. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Stefan Chulski authored
This patch add PPv23 version definition. PPv23 is new packet processor in CP115. Everything that supported by PPv22, also supported by PPv23. No functional changes in this stage. Signed-off-by:
-
Stefan Chulski authored
Currently we have PP2v1 and PP2v2 hw-versions, with some different handlers depending upon condition hw_version = MVPP21/MVPP22. In a future there will be also PP2v3. Let's use now the generic "if equal/notEqual MVPP21" for all cases instead of "if MVPP22". This patch does not change any functionality. It is not intended to introduce PP2v3. It just modifies MVPP21/MVPP22 check-condition bringing it to generic and unified form correct for new-code introducing and PP2v3 net-next generation. Signed-off-by:
-
Stefan Chulski authored
This patch adds CM3 memory map. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
-
Konstantin Porotchkin authored
CM3 SRAM address space will be used for Flow Control configuration. Signed-off-by:
Konstantin Porotchkin <kostap@marvell.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Stefan Chulski authored
Patch adds CM3 address space and PPv2.3 description. Signed-off-by:
-
Juergen Gross authored
In order to support the possibility of per-device event channel settings (e.g. lateeoi spurious event thresholds) add a xenbus device pointer to struct irq_info() and modify the related event channel binding interfaces to take the pointer to the xenbus device as a parameter instead of the domain id of the other side. While at it remove the stale prototype of bind_evtchn_to_irq_lateeoi(). Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by:
Wei Liu <wei.liu@kernel.org> Reviewed-by:
Paul Durrant <paul@xen.org> Signed-off-by:
-
Juergen Gross authored
In case of a common event for rx and tx queue the event should be regarded to be spurious if no rx and no tx requests are pending. Unfortunately the condition for testing that is wrong causing to decide a event being spurious if no rx OR no tx requests are pending. Fix that plus using local variables for rx/tx pending indicators in order to split function calls and if condition. Fixes: 23025393 ("xen/netback: use lateeoi irq binding") Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Wei Liu <wl@xen.org> Signed-off-by:
-
Vlad Buslov authored
The function fib6_walk_continue() cannot return a positive value when called from register_fib_notifier(), but ignoring causes static analyzer to generate warnings in users of register_fib_notifier() that try to convert returned error code to pointer with ERR_PTR(). Handle such case by explicitly checking for positive error values and converting them to -EINVAL in fib6_tables_dump(). Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Suggested-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'mlx5-for-upstream-2021-02-10' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-for-upstream-2021-02-10 Misc cleanups and trivial fixes for net-next 1) spelling mistakes 2) error path checks fixes 3) unused includes and struct fields cleanup 4) build error when MLX5_ESWITCH=no ==================== Signed-off-by:
-
Vladimir Oltean authored
Due to the fact that ic_dev->dev is kept open in ic_close_dev, I had thought that ic_dev will not be freed either. But that is not the case, but instead "everybody dies" when ipconfig cleans up, and just the net_device behind ic_dev->dev remains allocated but not ic_dev itself. This is a problem because in ic_close_devs, for every net device that we're about to close, we compare it against the list of lower interfaces of ic_dev, to figure out whether we should close it or not. But since ic_dev itself is subject to freeing, this means that at some point in the middle of the list of ipconfig interfaces, ic_dev will have been freed, and we would be still attempting to iterate through its list of lower interfaces while checking whether to bring down the remaining ipconfig interfaces. There are multiple ways to avoid the use-after-free: we could delay freeing ic_dev until the very end (outside the while loop). Or an even simpler one: we can observe that we don't need ic_dev when iterating through its lowers, only ic_dev->dev, structure which isn't ever freed. So, by keeping ic_dev->dev in a variable assigned prior to freeing ic_dev, we can avoid all use-after-free issues. Fixes: 46acf7bd ("Revert "net: ipv4: handle DSA enabled master network devices"") Reported-by:
kernel test robot <oliver.sang@intel.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Several years ago these two entries have been added, but it's not clear why. There's no trace that there has ever been such a chip version, and not even the r8101 vendor driver knows these id's. So let's disable detection, and if nobody complains remove them completely later. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== bonding: 3ad: support for 200G/400G ports and more verbose warning xk We'd like to have proper 200G and 400G support with 3ad bond mode, so we need to add new definitions for them in order to have separate oper keys, aggregated bandwidth and proper operation (patches 01 and 02). In patch 03 Ido changes the code to use pr_err_once instead of pr_warn_once which would help future detection of unsupported speeds. v2: patch 03: use pr_err_once instead of WARN_ONCE ==================== Signed-off-by: -
Ido Schimmel authored
The bond driver needs to be patched to support new ethtool speeds. Currently it emits a single warning [1] when it encounters an unknown speed. As evident by the two previous patches, this is not explicit enough. Instead, promote it to an error. [1] bond10: (slave swp1): unknown ethtool speed (200000) for port 1 (set it to 0) v2: * Use pr_err_once() instead of WARN_ONCE() Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
