- 22 May, 2022 40 commits
-
-
Lorenzo Bianconi authored
Add support for mt7986-eth driver available on mt7986 soc. Tested-by:
Sam Shih <sam.shih@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Lorenzo Bianconi authored
Simplify the code converting scratch_ring pointer to void Signed-off-by:
-
Lorenzo Bianconi authored
Simplify the code converting {tx,rx} ring dma pointer to void Signed-off-by: -
Lorenzo Bianconi authored
Introduce MTK_NETSYS_V2 support. MTK_NETSYS_V2 defines 32B TX/RX DMA descriptors. This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
Introduce reg_map structure to add the capability to support different register definitions. Move register definitions in mtk_regmap structure. This is a preliminary patch to introduce mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
Remove mtk_rx_dma structure layout dependency in mtk_rx_alloc/mtk_rx_clean. Initialize to 0 rxd3 and rxd4 in mtk_rx_alloc. This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
This is a preliminary to ad mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
Similar to tx counterpart, introduce rxd_size in mtk_soc_data data structure. This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
In order to remove mtk_tx_dma size dependency, introduce txd_size in mtk_soc_data data structure. Rely on txd_size in mtk_init_fq_dma() and mtk_dma_free() routines. This is a preliminary patch to add mt7986 ethernet support. Tested-by:
-
Lorenzo Bianconi authored
Move tx dma descriptor configuration in mtk_tx_set_dma_desc routine. This is a preliminary patch to introduce mt7986 ethernet support since it relies on a different tx dma descriptor layout. Tested-by:
-
Lorenzo Bianconi authored
Rely on GFP_KERNEL for dma descriptors mappings in mtk_tx_alloc(), mtk_rx_alloc() and mtk_init_fq_dma() since they are run in non-irq context. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce dts bindings for mt7986 soc in mediatek,net.yaml. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce ethernet nodes in mt7986 bindings in order to enable mt7986a/mt7986b ethernet support. Co-developed-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== eth: silence the GCC 12 array-bounds warnings Silence the array-bounds warnings in Ethernet drivers. v2 uses -Wno-array-bounds directly. ==================== Signed-off-by: -
Jakub Kicinski authored
GCC 12 currently generates a rather inconsistent warning: drivers/net/ethernet/broadcom/tg3.c:17795:51: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds] 17795 | struct tg3_napi *tnapi = &tp->napi[i]; | ~~~~~~~~^~~ i is guaranteed < tp->irq_max which in turn is either 1 or 5. There are more loops like this one in the driver, but strangely GCC 12 dislikes only this single one. Silence this silliness for now. Signed-off-by:Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
GCC 12 gets upset because driver allocates partial struct ice_aqc_sw_rules_elem buffers. The writes are within bounds. Silence these warnings for now, our build bot runs GCC 12 so we won't allow any new instances. Signed-off-by:
-
Jakub Kicinski authored
GCC 12 gets upset because in mtk_foe_entry_commit_subflow() this driver allocates a partial structure. The writes are within bounds. Silence these warnings for now, our build bot runs GCC 12 so we won't allow any new instances. Signed-off-by:
-
Vladimir Oltean authored
The "ok" tc action is useful when placed in front of a more generic filter to exclude some more specific rules from matching it. The ocelot switches can offload this tc action by creating an empty action vector (no _ENA fields set to 1). This makes sense for all of VCAP IS1, IS2 and ES0 (but not for PSFP). Add support for this action. Note that this makes the gact_drop_and_ok_test() selftest pass, where "action ok" is used in front of an "action drop" rule, both offloaded to VCAP IS2. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Streamline Ocelot tc-chains selftest This series changes the output and the argument format of the Ocelot switch selftest so that it is more similar to what can be found in tools/testing/selftests/net/forwarding/. ==================== Signed-off-by: -
Vladimir Oltean authored
Use the standard interface order h1, swp1, swp2, h2 that is used by the forwarding selftest framework. The previous order was confusing even with the ASCII drawing. That isn't needed anymore. This also drops the fixed MAC addresses and uses STABLE_MAC_ADDRS, which ensures the MAC addresses are unique. Signed-off-by:
-
Vladimir Oltean authored
This is a robotic rename as follows: eth0 -> swp1 eth1 -> swp2 eth2 -> h2 eth3 -> h1 This brings the selftest more in line with the other forwarding selftests, where h1 is connected to swp1, and h2 to swp2. Signed-off-by:
-
Vladimir Oltean authored
Bring this driver-specific selftest output in line with the other selftests. Before: Testing VLAN pop.. OK Testing VLAN push.. OK Testing ingress VLAN modification.. OK Testing egress VLAN modification.. OK Testing frame prioritization.. OK After: TEST: VLAN pop [ OK ] TEST: VLAN push [ OK ] TEST: Ingress VLAN modification [ OK ] TEST: Egress VLAN modification [ OK ] TEST: Frame prioritization [ OK ] Signed-off-by:
-
Jakub Kicinski authored
Most protocol-specific pointers in struct net_device are under a respective ifdef. Wireless is the notable exception. Since there's a sizable number of custom-built kernels for datacenter workloads which don't build wireless it seems reasonable to ifdefy those pointers as well. While at it move IPv4 and IPv6 pointers up, those are special for obvious reasons. Acked-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> # ieee802154 Acked-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Uwe Kleine-König authored
An error code returned by devm_clk_get() might have other meanings than "This clock doesn't exist". So use devm_clk_get_optional() and handle all remaining errors as fatal. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Tommaso Merciai authored
RGMII mode can be enable from dp83822 straps, and also writing bit 9 of register 0x17 - RMII and Status Register (RCSR). When phy_interface_is_rgmii rgmii mode must be enabled, same for contrary, this prevents malconfigurations of hw straps References: - https://www.ti.com/lit/gpn/dp83822i p66 Signed-off-by:
Tommaso Merciai <tommaso.merciai@amarulasolutions.com> Co-developed-by:
Michael Trimarchi <michael@amarulasolutions.com> Suggested-by:
Alberto Bianchi <alberto.bianchi@amarulasolutions.com> Tested-by:
-
Muhammad Usama Anjum authored
Add newly added stress_reuseport_listen object to .gitignore file. Fixes: ec8cb4f6 ("net: selftests: Stress reuseport listen") Signed-off-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by:
-
David S. Miller authored
David Howells says: ==================== rxrpc: Miscellaneous changes Here are some miscellaneous changes for AF_RXRPC: (1) Allow the list of local endpoints to be viewed through /proc. (2) Switch to using refcount_t for refcounting. (3) Fix a locking issue found by lockdep. (4) Autogenerate tracing symbol enums from symbol->string maps to make it easier to keep them in sync. (5) Return an error to sendmsg() if a call it tried to set up failed. Because it failed at this point, no notification will be generated for recvmsg to pick up - but userspace still needs to know about the failure. (6) Fix the selection of abort codes generated by internal events. In particular, rxrpc and kafs shouldn't be generating RX_USER_ABORT unless it's because userspace did something to cancel a call. (7) Adjust the interpretation and handling of certain ACK types to try and detect NAT changes causing a call to seem to start mid-flow from a different peer. ==================== Signed-off-by: -
David Howells authored
If a client's address changes, say if it is NAT'd, this can disrupt an in progress operation. For most operations, this is not much of a problem, but StoreData can be different as some servers modify the target file as the data comes in, so if a store request is disrupted, the file can get corrupted on the server. The problem is that the server doesn't recognise packets that come after the change of address as belonging to the original client and will bounce them, either by sending an OUT_OF_SEQUENCE ACK to the apparent new call if the packet number falls within the initial sequence number window of a call or by sending an EXCEEDS_WINDOW ACK if it falls outside and then aborting it. In both cases, firstPacket will be 1 and previousPacket will be 0 in the ACK information. Fix this by the following means: (1) If a client call receives an EXCEEDS_WINDOW ACK with firstPacket as 1 and previousPacket as 0, assume this indicates that the server saw the incoming packets from a different peer and thus as a different call. Fail the call with error -ENETRESET. (2) Also fail the call if a similar OUT_OF_SEQUENCE ACK occurs if the first packet has been hard-ACK'd. If it hasn't been hard-ACK'd, the ACK packet will cause it to get retransmitted, so the call will just be repeated. (3) Make afs_select_fileserver() treat -ENETRESET as a straight fail of the operation. (4) Prioritise the error code over things like -ECONNRESET as the server did actually respond. (5) Make writeback treat -ENETRESET as a retryable error and make it redirty all the pages involved in a write so that the VM will retry. Note that there is still a circumstance that I can't easily deal with: if the operation is fully received and processed by the server, but the reply is lost due to address change. There's no way to know if the op happened. We can examine the server, but a conflicting change could have been made by a third party - and we can't tell the difference. In such a case, a message like: kAFS: vnode modified {100058:146266} b7->b8 YFS.StoreData64 (op=2646a) will be logged to dmesg on the next op to touch the file and the client will reset the inode state, including invalidating clean parts of the pagecache. Reported-by:Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
David Howells <dhowells@redhat.com> cc: linux-afs@lists.infradead.org Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004811.html # v1 Signed-off-by:
-
David Howells authored
The RX_USER_ABORT code should really only be used to indicate that the user of the rxrpc service (ie. userspace) implicitly caused a call to be aborted - for instance if the AF_RXRPC socket is closed whilst the call was in progress. (The user may also explicitly abort a call and specify the abort code to use). Change some of the points of generation to use other abort codes instead: (1) Abort the call with RXGEN_SS_UNMARSHAL or RXGEN_CC_UNMARSHAL if we see ENOMEM and EFAULT during received data delivery and abort with RX_CALL_DEAD in the default case. (2) Abort with RXGEN_SS_MARSHAL if we get ENOMEM whilst trying to send a reply. (3) Abort with RX_CALL_DEAD if we stop hearing from the peer if we had heard from the peer and abort with RX_CALL_TIMEOUT if we hadn't. (4) Abort with RX_CALL_DEAD if we try to disconnect a call that's not completed successfully or been aborted. Reported-by:Jeffrey Altman <jaltman@auristor.com> Signed-off-by:
-
David Howells authored
If at the end of rxrpc sendmsg() or rxrpc_kernel_send_data() the call that was being given data was aborted remotely or otherwise failed, return an error rather than returning the amount of data buffered for transmission. The call (presumably) did not complete, so there's not much point continuing with it. AF_RXRPC considers it "complete" and so will be unwilling to do anything else with it - and won't send a notification for it, deeming the return from sendmsg sufficient. Not returning an error causes afs to incorrectly handle a StoreData operation that gets interrupted by a change of address due to NAT reconfiguration. This doesn't normally affect most operations since their request parameters tend to fit into a single UDP packet and afs_make_call() returns before the server responds; StoreData is different as it involves transmission of a lot of data. This can be triggered on a client by doing something like: dd if=/dev/zero of=/afs/example.com/foo bs=1M count=512 at one prompt, and then changing the network address at another prompt, e.g.: ifconfig enp6s0 inet 192.168.6.2 && route add 192.168.6.1 dev enp6s0 Tracing packets on an Auristor fileserver looks something like: 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 <ARP exchange for 192.168.6.2> 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.1 -> 192.168.6.2 RX 107 ACK Exceeds Window Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 29321 Call: 4 Source Port: 7000 Destination Port: 7001 The Auristor fileserver logs code -453 (RXGEN_SS_UNMARSHAL), but the abort code received by kafs is -5 (RX_PROTOCOL_ERROR) as the rx layer sees the condition and generates an abort first and the unmarshal error is a consequence of that at the application layer. Reported-by:
-
David Howells authored
Automatically generate trace tag enums from the symbol -> string mapping tables rather than having the enums as well, thereby reducing duplicated data. Signed-off-by:
-
David Howells authored
There's a locking issue with the per-netns list of calls in rxrpc. The pieces of code that add and remove a call from the list use write_lock() and the calls procfile uses read_lock() to access it. However, the timer callback function may trigger a removal by trying to queue a call for processing and finding that it's already queued - at which point it has a spare refcount that it has to do something with. Unfortunately, if it puts the call and this reduces the refcount to 0, the call will be removed from the list. Unfortunately, since the _bh variants of the locking functions aren't used, this can deadlock. ================================ WARNING: inconsistent lock state 5.18.0-rc3-build4+ #10 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/2/25 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff888107ac4038 (&rxnet->call_lock){+.?.}-{2:2}, at: rxrpc_put_call+0x103/0x14b {SOFTIRQ-ON-W} state was registered at: ... Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->call_lock); <Interrupt> lock(&rxnet->call_lock); *** DEADLOCK *** 1 lock held by ksoftirqd/2/25: #0: ffff8881008ffdb0 ((&call->timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x23d Changes ======= ver #2) - Changed to using list_next_rcu() rather than rcu_dereference() directly. Fixes: 17926a79 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: -
David Howells authored
Move to using refcount_t rather than atomic_t for refcounts in rxrpc. Signed-off-by:
-
David Howells authored
Allow the list of in-use local UDP endpoints in the current network namespace to be viewed in /proc. To aid with this, the endpoint list is converted to an hlist and RCU-safe manipulation is used so that the list can be read with only the RCU read lock held. Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: a few more small items This series consists of three small sets of changes. Version 2 adds a patch that avoids a warning that occurs when handling a modem crash (I unfortunately didn't notice it earlier). All other patches are the same--just rebased. The first three patches allow a few endpoint features to be specified. At this time, currently-defined endpoints retain the same configuration, but when the monitor functionality is added in the next cycle these options will be required. The fourth patch simply removes an unused function, explaining also why it would likely never be used. The fifth patch is new. It counts the number of modem TX endpoints and uses it to determine how many TREs a transaction needs when when handling a modem crash. It is needed to avoid exceeding the limited number of commands imposed by the last four patches. And the last four patches refactor code related to IPA immediate commands, eliminating an unused field and then simplifying and removing some unneeded code. ==================== Signed-off-by: -
Alex Elder authored
The 64-bit data field in a transaction is not used for commands. And the opcode array is *only* used for commands. They're (currently) the same size; save a little space in the transaction structure by enclosing the two fields in a union. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The ipa_cmd_info structure now contains only one field, and it's an enumerated type whose values all fit in 8 bits. Currently we'll never use more than 8 TREs in a command transaction, and we can represent that number of command opcodes in the same space as a 64 bit pointer to an ipa_cmd_info structure. Define IPA_COMMAND_TRANS_TRE_MAX as the maximum number of TREs that can be in a command transaction. Replace the info pointer in a transaction with a fixed-size array named cmd_opcode[] of that many bytes. Store the opcode in this array when adding a command TRE to a transaction, as was done previously for the info array. This makes the ipa_cmd_info unused, so get rid of it. When committing an immediate command transaction, use the channel's Boolean command flag to determine whether to fill in the opcode, which will be taken (as before) from the array in the transaction. This makes the command info pool unnecessary, so get rid of it. Signed-off-by:
-
