- 24 Mar, 2020 40 commits
-
-
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 <andre.przywara@arm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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:
Andrew Lunn <andrew@lunn.ch> Signed-off-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:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-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:
-
Vladimir Oltean authored
Because the PTP_CLK pin starts toggling only at a time higher than the current PTP clock, this helper from the time-aware shaper code comes in handy here as well. We'll use it to transform generic user input for the perout request into valid input for the sja1105 hardware. Signed-off-by:
-
Vladimir Oltean authored
These fields configure the destination and source MAC address that the switch will put in the Ethernet frames sent towards the CPU port that contain RX timestamps for PTP. These fields do not enable the feature itself, that is configured via SEND_META0 and SEND_META1 in the General Params table. The implication of this patch is that the AVB Params table will always be present in the static config. Which doesn't really hurt. This is needed because in a future patch, we will add another field from this table, CAS_MASTER, for configuring the PTP_CLK pin function. That can be configured irrespective of whether RX timestamping is enabled or not, so always having this table present is going to simplify things a bit. Signed-off-by:
-
Logan Magee authored
checkpatch found a lack of appropriate whitespace after certain keywords as per the style guide. Add it in. Signed-off-by:
Logan Magee <mageelog@gmail.com> Signed-off-by:
-
David S. Miller authored
Dejin Zheng says: ==================== introduce read_poll_timeout This patch sets is introduce read_poll_timeout macro, it is an extension of readx_poll_timeout macro. the accessor function op just supports only one parameter in the readx_poll_timeout macro, but this macro can supports multiple variable parameters for it. so functions like phy_read(struct phy_device *phydev, u32 regnum) and phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum) can use this poll timeout framework. the first patch introduce read_poll_timeout macro, and the second patch redefined readx_poll_timeout macro by read_poll_timeout(), and the other patches are examples using read_poll_timeout macro. v6 -> v7: - add a parameter to supports that it can sleep some time before read operation in read_poll_timeout macro. - add prefix with double underscores for some variable to avoid any variable re-declaration or shadowing in patch 3 and patch 7. v5 -> v6: - add some check to keep the code more similar in patch 8 v4 -> v5: - add some msleep() before call phy_read_mmd_poll_timeout() to keep the code more similar in patch 6 and patch 9. - add a patch of drop by v4, it can add msleep before call phy_read_poll_timeout() to keep the code more similar. v3 -> v4: - add 3 examples of using new functions. - deal with precedence issues for parameter cond. - drop a patch about phy_poll_reset() function. v2 -> v3: - modify the parameter order of newly added functions. phy_read_mmd_poll_timeout(val, cond, sleep_us, timeout_us, \ phydev, devaddr, regnum) || \/ phy_read_mmd_poll_timeout(phydev, devaddr regnum, val, cond, \ sleep_us, timeout_us) phy_read_poll_timeout(val, cond, sleep_us, timeout_us, \ phydev, regnum) || \/ phy_read_poll_timeout(phydev, regnum, val, cond, sleep_us, \ timeout_us) v1 -> v2: - passed a phydev, device address and a reg to replace args... parameter in phy_read_mmd_poll_timeout() by Andrew Lunn 's suggestion in patch 3. Andrew Lunn <andrew@lunn.ch>, Thanks very much for your help! - also in patch 3, handle phy_read_mmd return an error(the return value < 0) in phy_read_mmd_poll_timeout(). Thanks Andrew again. - in patch 6, pass a phydev and a reg to replace args... parameter in phy_read_poll_timeout(), and also handle the phy_read() function's return error. ==================== Signed-off-by: -
Dejin Zheng authored
use phy_read_poll_timeout() to replace the poll codes for simplify tja11xx_check() function. Suggested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Dejin Zheng authored
use phy_read_poll_timeout() to replace the poll codes for simplify lan87xx_read_status() function. Suggested-by:
-
Dejin Zheng authored
use phy_read_poll_timeout() to replace the poll codes for simplify the code in phy_poll_reset() function. Reviewed-by:
-
Dejin Zheng authored
it is sometimes necessary to poll a phy register by phy_read() function until its value satisfies some condition. introduce phy_read_poll_timeout() macros that do this. Suggested-by:
-
Dejin Zheng authored
use phy_read_mmd_poll_timeout() to replace the poll codes for simplify mv3310_reset() function. Suggested-by:
-
Dejin Zheng authored
use phy_read_mmd_poll_timeout() to replace the poll codes for simplify aqr107_wait_reset_complete() function. Reviewed-by:
-
Dejin Zheng authored
use phy_read_mmd_poll_timeout() to replace the poll codes for simplify bcm84881_wait_init() function. Reviewed-by:
-
Dejin Zheng authored
it is sometimes necessary to poll a phy register by phy_read_mmd() function until its value satisfies some condition. introduce phy_read_mmd_poll_timeout() macros that do this. Suggested-by:
-
Dejin Zheng authored
redefined readx_poll_timeout macro by read_poll_timeout to simplify the code. Signed-off-by:
-
Dejin Zheng authored
this macro is an extension of readx_poll_timeout macro. the accessor function op just supports only one parameter in the readx_poll_timeout macro, but this macro can supports multiple variable parameters for it. so functions like phy_read(struct phy_device *phydev, u32 regnum) and phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum) can also use this poll timeout core. and also expand it can sleep some time before read operation. Signed-off-by:
-
David Laight authored
Previous changes to the IP routing code have removed all the tests for the DS_HOST route flag. Remove the flags and all the code that sets it. Signed-off-by:
David Laight <david.laight@aculab.com> Acked-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Zheng zengkai authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/cavium/thunder/nicvf_queues.c: In function nicvf_sq_free_used_descs: drivers/net/ethernet/cavium/thunder/nicvf_queues.c:1182:12: warning: variable tail set but not used [-Wunused-but-set-variable] It's not used since commit 4863dea3("net: Adding support for Cavium ThunderX network controller"), so remove it. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zheng zengkai <zhengzengkai@huawei.com> Signed-off-by:
-
Florian Fainelli authored
Provide a flow_dissect callback which returns the network offset and where to find the skb protocol, given the tags structure a common function works for both tagging formats that are supported. Signed-off-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== devlink: Preparations for trap policers support This patch set prepares the code for devlink-trap policer support in a follow-up patch set [1][2]. No functional changes intended. Policers are going to be added as attributes of packet trap groups, which are entities used to aggregate logically related packet traps. This will allow users, for example, to limit all the packets that encountered an exception during routing to 10Kpps. However, currently, device drivers register their packet trap groups implicitly when they register their packet traps via devlink_traps_register(). This makes it difficult to pass additional attributes for the groups. For example, the policer bound to the group. Therefore, this patch set converts device drivers to explicitly register their packet trap groups. This will later allow these drivers to register the group with additional attributes, if any. ==================== Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Packet trap groups are now explicitly registered by drivers and not implicitly registered when the packet traps are registered. Therefore, there is no need to encode entire group structure the trap is associated with inside the trap structure. Instead, only pass the group identifier. Refer to it as initial group identifier, as future patches will allow user space to move traps between groups. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Now that drivers explicitly register their supported packet trap groups there is no for devlink to create them on-demand and destroy them when their reference count reaches zero. Signed-off-by:
-
Ido Schimmel authored
Use the previously added API to explicitly register / unregister supported packet trap groups. This is in preparation for future patches that will enable drivers to pass additional group attributes, such as associated policer identifier. Signed-off-by:
-
Ido Schimmel authored
Use the previously added API to explicitly register / unregister supported packet trap groups. This is in preparation for future patches that will enable drivers to pass additional group attributes, such as associated policer identifier. Signed-off-by:
-
Ido Schimmel authored
Currently, packet trap groups are implicitly registered by drivers upon packet trap registration. When the traps are registered, each is associated with a group and the group is created by devlink, if it does not exist already. This makes it difficult for drivers to pass additional attributes for the groups. Therefore, as a preparation for future patches that require passing additional group attributes, add an API to explicitly register / unregister these groups. Next patches will convert existing drivers to use this API. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: improvements for scheduled task handling This series includes some improvements for handling of scheduled tasks. ==================== Signed-off-by: -
Heiner Kallweit authored
So far only the reset bit it set, but the handler executing the reset is not scheduled. Therefore nothing will happen until some other action schedules the handler. Improve this by ensuring that the handler is scheduled. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
The current implementation makes the implicit assumption that if a bit is set, then the work is scheduled already. Remove the need for this implicit assumption and call schedule_work() always. It will check internally whether the work is scheduled already. Signed-off-by:
-
Heiner Kallweit authored
Currently rtl_task() is designed to handle a large number of tasks. However we have just one, so we can remove some overhead. Signed-off-by:
-
