- 26 Mar, 2020 15 commits
-
-
Parav Pandit authored
Subsequent patch protects eswitch mode changes across sriov and devlink interfaces. It is desirable for eswitch to provide thread safe eswitch enable and disable APIs. Hence, extend eswitch enable API to optionally update num_vfs when requested. In subsequent patch, eswitch num_vfs are updated after all the eswitch users eswitch drops its reference count. Reviewed-by:
Roi Dayan <roid@mellanox.com> Reviewed-by:
Bodong Wang <bodong@mellanox.com> Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Parav Pandit authored
In order to check eswitch state under a lock, prepare code to split capability check and eswitch state check into two helper functions. Reviewed-by:
-
Parav Pandit authored
devlink_nl_cmd_eswitch_set_doit() doesn't hold devlink->lock mutex while invoking driver callback. This is likely due to eswitch mode setting involves adding/remove devlink ports, health reporters or other devlink objects for a devlink device. So it is driver responsiblity to ensure thread safe eswitch state transition happening via either sriov legacy enablement or via devlink eswitch set callback. Therefore, get() callback should also be invoked without holding devlink->lock mutex. Vendor driver can use same internal lock which it uses during eswitch mode set() callback. This makes get() and set() implimentation symmetric in devlink core and in vendor drivers. Hence, remove holding devlink->lock mutex during eswitch get() callback. Failing to do so results into below deadlock scenario when mlx5_core driver is improved to handle eswitch mode set critical section invoked by devlink and sriov sysfs interface in subsequent patch. devlink_nl_cmd_eswitch_set_doit() mlx5_eswitch_mode_set() mutex_lock(esw->mode_lock) <- Lock A [...] register_devlink_port() mutex_lock(&devlink->lock); <- lock B mutex_lock(&devlink->lock); <- lock B devlink_nl_cmd_eswitch_get_doit() mlx5_eswitch_mode_get() mutex_lock(esw->mode_lock) <- Lock A In subsequent patch, mlx5_core driver uses its internal lock during get() and set() eswitch callbacks. Other drivers have been inspected which returns either constant during get operations or reads the value from already allocated structure. Hence it is safe to remove the lock in get( ) callback and let vendor driver handle it. Reviewed-by:Jiri Pirko <jiri@mellanox.com> Reviewed-by:
-
Parav Pandit authored
mlx5_unload_one() always returns 0. Simplify callers of mlx5_unload_one() and remove the dead code. Reviewed-by:
Moshe Shemesh <moshe@mellanox.com> Signed-off-by:
-
Parav Pandit authored
mlx5_register_device() doesn't check for any error and always returns 0. Simplify mlx5_register_device() to return void and its caller, remove dead code related to it. Reviewed-by:
-
Eli Cohen authored
Group version is used when modifying a rule is allowed (FLOW_ACT_NO_APPEND is clear) to detect a case where the rule was found but while the groups where unlocked a new FTE was added. In this case, the added FTE could be one with identical match value so we need to attempt again with group lock held. Change the code so version is retrieved only when FLOW_ACT_NO_APPEND is cleared. As result, later compare can also be avoided if FLOW_ACT_NO_APPEND is cleared. Also improve comments text. Signed-off-by:
Eli Cohen <eli@mellanox.com> Reviewed-by:
-
Eli Cohen authored
FTE version is not used anywhere in the code so avoid incrementing it. Signed-off-by:
-
Eli Cohen authored
When adding a rule to a flow group we need increment the version of the group. Current code fails to do that and as a result, when trying to add a rule, we will fail to discover a case where an FTE with the same match value was added while we scanned the groups of the same match criteria, thus we may try to add an FTE that was already added. Signed-off-by:
-
Eli Cohen authored
Instead of using two different structs for searching groups with the same match, use a single struct and thus simplify the code, make it more readable and smaller size which means less code cache misses. text data bss dec hex before: 35524 2744 0 38268 957c after: 35038 2744 0 37782 9396 When testing add 70000 rules, delete all the rules, and repeat three times taking the average, we get (time in seconds): Before the change: insert 16.80, delete 11.02 After the change: insert 16.55, delete 10.95 Signed-off-by:Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
-
Roi Dayan authored
The correct type is u32. Fixes: d18296ff ("net/mlx5: E-Switch, Introduce global tables") Signed-off-by:
Paul Blakey <paulb@mellanox.com> Signed-off-by:
-
Roi Dayan authored
We allocate a temporary memory but forget to free it. Fixes: 11b717d6 ("net/mlx5: E-Switch, Get reg_c0 value on CQE") Signed-off-by:
-
Paul Blakey authored
Register c0 loopback is needed to fully support chains and prios. Enable chains and prio only if loopback (of reg c1 which came together with c0), is enabled. To be able to check that, move enabling of loopback before eswitch chains init. Signed-off-by:
-
Paul Blakey authored
Reg c0/c1 matching, rewrite of regs c0/c1, and copy header of regs c1,B is needed for the restore table to function, might not be supported by firmware, and creation of the restore table or the copy header will fail. Check reg_c1 loopback support, as firmware which supports this, should have all of the above. Fixes: 11b717d6 ("net/mlx5: E-Switch, Get reg_c0 value on CQE") Signed-off-by:
-
wenxu authored
The function mlx5e_rep_setup_ft_cb check chain_index is zero twice. Signed-off-by:
wenxu <wenxu@ucloud.cn> Signed-off-by:
-
Dan Carpenter authored
The actions_match_supported() function returns a bool, true for success and false for failure. This error path is returning a negative which is cast to true but it should return false. Fixes: 4c3844d9 ("net/mlx5e: CT: Introduce connection tracking") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
- 25 Mar, 2020 2 commits
-
-
Eric Dumazet authored
TCP recvmsg() calls skb_copy_datagram_iter(), which calls an indirect function (cb pointing to simple_copy_to_iter()) for every MSS (fragment) present in the skb. CONFIG_RETPOLINE=y forces a very expensive operation that we can avoid thanks to indirect call wrappers. This patch gives a 13% increase of performance on a single flow, if the bottleneck is the thread reading the TCP socket. Fixes: 950fcaec ("datagram: consolidate datagram copy to iter helpers") Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
YueHaibing authored
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c: In function cxgb4_get_free_ftid: drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c:547:23: warning: variable tab set but not used [-Wunused-but-set-variable] commit 8d174351 ("cxgb4: rework TC filter rule insertion across regions") involved this, remove it. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
- 24 Mar, 2020 23 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:
-
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: -
Andre Przywara authored
Similar to axienet, the temac driver is now architecture agnostic, and can be at least compiled for several architectures. Especially the fact that this is a soft IP for implementing in FPGAs makes the current restriction rather pointless, as it could literally appear on any architecture, as long as an FPGA is connected to the bus. The driver hasn't been actually tried on any hardware, it is just a drive-by patch when doing the same for axienet (a similar patch for axienet is already merged). This (temac and axienet) have been compile-tested for: alpha hppa64 microblaze mips64 powerpc powerpc64 riscv64 s390 sparc64 (using kernel.org cross compilers). Signed-off-by:
-
Vladyslav Tarasiuk authored
Currently, ethtool feature mask for checksum command is ORed with NETIF_F_FCOE_CRC_BIT, which is bit's position number, instead of the actual feature bit - NETIF_F_FCOE_CRC. The invalid bitmask here might affect unrelated features when toggling TX checksumming. For example, TX checksumming is always mistakenly reported as enabled on the netdevs tested (mlx5, virtio_net). Fixes: f70bb065 ("ethtool: update mapping of features to legacy ioctl requests") Signed-off-by:
Vladyslav Tarasiuk <vladyslavt@mellanox.com> Reviewed-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Dejin Zheng authored
use readl_poll_timeout() to replace the poll codes for simplify iproc_mdio_wait_for_idle() function Signed-off-by:
Dejin Zheng <zhengdejin5@gmail.com> Reviewed-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2020-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.7 Second set of patches for v5.7. Lots of cleanup patches this time, but of course various new features as well fixes. When merging with wireless-drivers this pull request has a conflict in: drivers/net/wireless/intel/iwlwifi/pcie/drv.c To solve that just drop the changes from commit cf52c8a7 in wireless-drivers and take the hunk from wireless-drivers-next as is. The list of specific subsystem device IDs are not necessary after commit d6f2134a (in wireless-drivers-next) anymore, the detection is based on other characteristics of the devices. Major changes: qtnfmac * support WPA3 SAE and OWE in AP mode ath10k * support for getting btcoex settings from Device Tree * support QCA9377 SDIO device ath11k * add HE rate accounting * add thermal sensor and cooling devices mt76 * MT7663 support for the MT7615 driver ==================== Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== PTP_CLK pin configuration for SJA1105 DSA driver This series adds support for the PTP_CLK pin on SJA1105 to be configured via the PTP subsystem, in the "periodic output" and "external timestamp input" modes. ==================== Signed-off-by: -
Vladimir Oltean authored
The SJA1105 switch family has a PTP_CLK pin which emits a signal with fixed 50% duty cycle, but variable frequency and programmable start time. On the second generation (P/Q/R/S) switches, this pin supports even more functionality. The use case described by the hardware documents talks about synchronization via oneshot pulses: given 2 sja1105 switches, arbitrarily designated as a master and a slave, the master emits a single pulse on PTP_CLK, while the slave is configured to timestamp this pulse received on its PTP_CLK pin (which must obviously be configured as input). The difference between the timestamps then exactly becomes the slave offset to the master. The only trouble with the above is that the hardware is very much tied into this use case only, and not very generic beyond that: - When emitting a oneshot pulse, instead of being told when to emit it, the switch just does it "now" and tells you later what time it was, via the PTPSYNCTS register. [ Incidentally, this is the same register that the slave uses to collect the ext_ts timestamp from, too. ] - On the sync slave, there is no interrupt mechanism on reception of a new extts, and no FIFO to buffer them, because in the foreseen use case, software is in control of both the master and the slave pins, so it "knows" when there's something to collect. These 2 problems mean that: - We don't support (at least yet) the quirky oneshot mode exposed by the hardware, just normal periodic output. - We abuse the hardware a little bit when we expose generic extts. Because there's no interrupt mechanism, we need to poll at double the frequency we expect to receive a pulse. Currently that means a non-configurable "twice a second". Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
The AVB table contains the CAS_MASTER field (to be added in the next patch) which decides the direction of the PTP_CLK pin. Reconfiguring this field dynamically is highly preferable to having to reset the switch and upload a new static configuration, so we add support for exactly that. Signed-off-by:
-
