- 25 Nov, 2020 15 commits
-
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Divya Koppera <Divya.Koppera@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Marek Vasut <marex@denx.de> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Divya Koppera <Divya.Koppera@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Marek Vasut <marex@denx.de> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Mathias Kresin <dev@kresin.me> Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Mathias Kresin <dev@kresin.me> Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Sven Van Asbroeck authored
The driver's ISR sends a 'software interrupt' event to the probe() thread using the following method: - probe(): write 0 to flag, enable s/w interrupt - probe(): poll on flag, relax using usleep_range() - ISR : write 1 to flag Replace with wake_up() / wait_event_timeout(). Besides being easier to get right, this abstraction has better timing and memory consistency properties. Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430 Signed-off-by:
Sven Van Asbroeck <thesven73@gmail.com> Link: https://lore.kernel.org/r/20201123191529.14908-2-TheSven73@gmail.comSigned-off-by:
-
Sven Van Asbroeck authored
For no apparent reason, this function reads the INT_STS register, and checks if the software interrupt bit is set. These things have already been carried out by this function's only caller. Clean up by removing the redundant code. Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430 Signed-off-by:
-
- 24 Nov, 2020 25 commits
-
-
Jakub Kicinski authored
Lorenzo Bianconi says: ==================== mvneta: access skb_shared_info only on last frag Build skb_shared_info on mvneta_rx_swbm stack and sync it to xdp_buff skb_shared_info area only on the last fragment. Avoid avoid unnecessary xdp_buff initialization in mvneta_rx_swbm routine. This a preliminary series to complete xdp multi-buff in mvneta driver. ==================== Link: https://lore.kernel.org/r/cover.1605889258.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Build skb_shared_info on mvneta_rx_swbm stack and sync it to xdp_buff skb_shared_info area only on the last fragment. Leftover cache miss in mvneta_swbm_rx_frame will be addressed introducing mb bit in xdp_buff/xdp_frame struct Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Lorenzo Bianconi authored
Pass skb_shared_info pointer from mvneta_xdp_put_buff caller. This is a preliminary patch to reduce accesses to skb_shared_info area and reduce cache misses. Remove napi parameter in mvneta_xdp_put_buff signature since it is always run in NAPI context Signed-off-by:
-
Lorenzo Bianconi authored
Explicitly initialize mandatory fields defining xdp_buff struct in mvneta_rx_swbm routine Signed-off-by:
-
Stefan Chulski authored
Tx/Rx FIFO is a HW resource limited by total size, but shared by all ports of same CP110 and impacting port-performance. Do not divide the FIFO for ports which are not enabled in DTS, so active ports could have more FIFO. No change in FIFO allocation if all 3 ports on the communication processor enabled in DTS. The active port mapping should be done in probe before FIFO-init. Signed-off-by:
Stefan Chulski <stefanc@marvell.com> Reviewed-by:
Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/1606154073-28267-1-git-send-email-stefanc@marvell.comSigned-off-by:
-
Lorenzo Bianconi authored
Introduce page_pool_put_page_bulk() entry into the API section of page_pool.rst Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Heiner Kallweit authored
In bug report [0] a warning in r8169 driver was reported that was caused by an invalid GSO SKB (gso_type was 0). See [1] for a discussion about this issue. Still the origin of the invalid GSO SKB isn't clear. It shouldn't be a network drivers task to check for invalid GSO SKB's. Also, even if issue [0] can be fixed, we can't be sure that a similar issue doesn't pop up again at another place. Therefore let gso_features_check() check for such invalid GSO SKB's. [0] https://bugzilla.kernel.org/show_bug.cgi?id=209423 [1] https://www.spinics.net/lists/netdev/msg690794.htmlSigned-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/97c78d21-7f0b-d843-df17-3589f224d2cf@gmail.comSigned-off-by:
-
Colin Ian King authored
There are spelling mistakes in two dev_err messages. Fix them. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201123103452.197708-1-colin.king@canonical.comSigned-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Add support for blackhole nexthops This patch set adds support for blackhole nexthops in mlxsw. These nexthops are exactly the same as other nexthops, but instead of forwarding packets to an egress router interface (RIF), they are programmed to silently drop them. Patches #1-#4 are preparations. Patch #5 adds support for blackhole nexthops and removes the check that prevented them from being programmed. Patch #6 adds a selftests over mlxsw which tests that blackhole nexthops can be programmed and are marked as offloaded. Patch #7 extends the existing nexthop forwarding test to also test blackhole functionality. Patches #8-#10 add support for a new packet trap ('blackhole_nexthop') which should be triggered whenever packets are dropped by a blackhole nexthop. Obviously, by default, the trap action is set to 'drop' so that dropped packets will not be reported. ==================== Link: https://lore.kernel.org/r/20201123071230.676469-1-idosch@idosch.orgSigned-off-by: -
Ido Schimmel authored
Test that packets hitting a blackhole nexthop are trapped to the CPU when the trap is enabled. Test that packets are not reported when the trap is disabled. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
Register with devlink the blackhole_nexthop trap so that mlxsw will be able to report packets dropped due to a blackhole nexthop. The internal trap identifier is "DISCARD_ROUTER3", which traps packets dropped in the adjacency table. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
Add a packet trap to report packets that were dropped due to a blackhole nexthop. Signed-off-by:
-
Ido Schimmel authored
Test that IPv4 and IPv6 ping fail when the route is using a blackhole nexthop or a group with a blackhole nexthop. Test that ping passes when the route starts using a valid nexthop. Signed-off-by:
-
Ido Schimmel authored
Test the mlxsw allows blackhole nexthops to be installed and that the nexthops are marked as offloaded. Signed-off-by:
-
Ido Schimmel authored
Add support for blackhole nexthops by programming them to the adjacency table with a discard action. Signed-off-by:
-
Ido Schimmel authored
The two are the same, but for blackhole nexthops we will not have an associated neighbour struct, so resolve the RIF from the nexthop struct itself instead. Signed-off-by:
-
Ido Schimmel authored
Now that the driver creates a loopback RIF during its initialization, it can be used to program the adjacency entries for unresolved nexthops instead of other RIFs. The loopback RIF is guaranteed to exist for the entire life time of the driver, unlike other RIFs that come and go. Signed-off-by:
-
Ido Schimmel authored
Unresolved nexthops are currently written to the adjacency table with a discard action. Packets hitting such entries are trapped to the CPU via the 'DISCARD_ROUTER3' trap which can be enabled or disabled on demand, but is always enabled in order to ensure the kernel can resolve the unresolved neighbours. This trap will be needed for blackhole nexthops support. Therefore, move unresolved nexthops to explicitly program the adjacency entries with a trap action and a different trap identifier, 'RTR_EGRESS0'. Signed-off-by:
-
Ido Schimmel authored
Up until now RIFs (router interfaces) were created on demand (e.g., when an IP address was added to a netdev). However, sometimes the device needs to be provided with a RIF when one might not be available. For example, adjacency entries that drop packets need to be programmed with an egress RIF despite the RIF not being used to forward packets. Create such a RIF during initialization so that it could be used later on to support blackhole nexthops. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fsJakub Kicinski authored
David Howells says: ==================== rxrpc: Prelude to gssapi support Here are some patches that do some reorganisation of the security class handling in rxrpc to allow implementation of the RxGK security class that will allow AF_RXRPC to use GSSAPI-negotiated tokens and better crypto. The RxGK security class is not included in this patchset. It does the following things: (1) Add a keyrings patch to provide the original key description, as provided to add_key(), to the payload preparser so that it can interpret the content on that basis. Unfortunately, the rxrpc_s key type wasn't written to interpret its payload as anything other than a string of bytes comprising a key, but for RxGK, more information is required as multiple Kerberos enctypes are supported. (2) Remove the rxk5 security class key parsing. The rxk5 class never got rolled out in OpenAFS and got replaced with rxgk. (3) Support the creation of rxrpc keys with multiple tokens of different types. If some types are not supported, the ENOPKG error is suppressed if at least one other token's type is supported. (4) Punt the handling of server keys (rxrpc_s type) to the appropriate security class. (5) Organise the security bits in the rxrpc_connection struct into a union to make it easier to override for other classes. (6) Move some bits from core code into rxkad that won't be appropriate to rxgk. * tag 'rxrpc-next-20201123' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: rxrpc: Ask the security class how much space to allow in a packet rxrpc: rxkad: Don't use pskb_pull() to advance through the response packet rxrpc: Organise connection security to use a union rxrpc: Don't reserve security header in Tx DATA skbuff rxrpc: Merge prime_packet_security into init_connection_security rxrpc: Fix example key name in a comment rxrpc: Ignore unknown tokens in key payload unless no known tokens rxrpc: Make the parsing of xdr payloads more coherent rxrpc: Allow security classes to give more info on server keys rxrpc: Don't leak the service-side session key to userspace rxrpc: Hand server key parsing off to the security class rxrpc: Split the server key type (rxrpc_s) into its own file rxrpc: Don't retain the server key in the connection rxrpc: Support keys with multiple authentication tokens rxrpc: List the held token types in the key description in /proc/keys rxrpc: Remove the rxk5 security class as it's now defunct keys: Provide the original description to the key preparser ==================== Link: https://lore.kernel.org/r/160616220405.830164.2239716599743995145.stgit@warthog.procyon.org.ukSigned-off-by: -
Vincent Whitchurch authored
This driver uses a normal timer for TX coalescing, which means that the with the default tx-usecs of 1000 microseconds the cleanups actually happen 10 ms or more later with HZ=100. This leads to very low througput with TCP when bridged to a slow link such as a 4G modem. Fix this by using an hrtimer instead. On my ARM platform with HZ=100 and the default TX coalescing settings (tx-frames 25 tx-usecs 1000), with "tc qdisc add dev eth0 root netem delay 60ms 40ms rate 50Mbit" run on the server, netperf's TCP_STREAM improves from ~5.5 Mbps to ~100 Mbps. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20201120150208.6838-1-vincent.whitchurch@axis.comSigned-off-by:
-
Christophe JAILLET authored
s/tranport/transport/ Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20201122180704.1366636-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Jakub Kicinski authored
linux/netdevice.h is included in very many places, touching any of its dependecies causes large incremental builds. Drop the linux/ethtool.h include, linux/netdevice.h just needs a forward declaration of struct ethtool_ops. Fix all the places which made use of this implicit include. Acked-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Shannon Nelson <snelson@pensando.io> Reviewed-by:
-
Christophe JAILLET authored
Memory allocation are done with 'dma_alloc_coherent()'. Be consistent and use 'dma_free_coherent()' to free the corresponding memory. Signed-off-by:
-
Christophe JAILLET authored
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. Signed-off-by:
-
