summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-01-31rxrpc: Show consumed and freed packets as non-dropped in dropwatchDavid Howells
Set a reason when freeing a packet that has been consumed such that dropwatch doesn't complain that it has been dropped. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Remove local->defrag_semDavid Howells
We no longer need local->defrag_sem as all DATA packet transmission is now done from one thread, so remove it. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Don't lock call->tx_lock to access call->tx_bufferDavid Howells
call->tx_buffer is now only accessed within the I/O thread (->tx_sendmsg is the way sendmsg passes packets to the I/O thread) so there's no need to lock around it. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Simplify ACK handlingDavid Howells
Now that general ACK transmission is done from the same thread as incoming DATA packet wrangling, there's no possibility that the SACK table will be being updated by the latter whilst the former is trying to copy it to an ACK. This means that we can safely rotate the SACK table whilst updating it without having to take a lock, rather than keeping all the bits inside it in fixed place and copying and then rotating it in the transmitter. Therefore, simplify SACK handing by keeping track of starting point in the ring and rotate slots down as we consume them. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: De-atomic call->ackr_window and call->ackr_nr_unackedDavid Howells
call->ackr_window doesn't need to be atomic as ACK generation and ACK transmission are now done in the same thread, so drop the atomic64 handling and split it into two separate members. Similarly, call->ackr_nr_unacked doesn't need to be atomic now either. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Generate extra pings for RTT during heavy-receive callDavid Howells
When doing a call that has a single transmitted data packet and a massive amount of received data packets, we only ping for one RTT sample, which means we don't get a good reading on it. Fix this by converting occasional IDLE ACKs into PING ACKs to elicit a response. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Allow a delay to be injected into packet receptionDavid Howells
If CONFIG_AF_RXRPC_DEBUG_RX_DELAY=y, then a delay is injected between packets and errors being received and them being made available to the processing code, thereby allowing the RTT to be artificially increased. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Convert call->recvmsg_lock to a spinlockDavid Howells
Convert call->recvmsg_lock to a spinlock as it's only ever write-locked. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
2023-01-31rxrpc: Shrink the tabulation in the rxrpc trace header a bitDavid Howells
Shrink the tabulation in the rxrpc trace header a bit to allow for fields with long type names that have been removed. Signed-off-by: David Howells <dhowells@redhat.com>
2023-01-31rxrpc: Remove whitespace before ')' in trace headerDavid Howells
Work around checkpatch warnings in the rxrpc trace header by removing whitespace before ')' on lines defining the trace record struct. Signed-off-by: David Howells <dhowells@redhat.com>
2023-01-31kunit: fix kunit_test_init_section_suites(...)Brendan Higgins
Looks like kunit_test_init_section_suites(...) was messed up in a merge conflict. This fixes it. kunit_test_init_section_suites(...) was not updated to avoid the extra level of indirection when .kunit_test_suites was flattened. Given no-one was actively using it, this went unnoticed for a long period of time. Fixes: e5857d396f35 ("kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites") Signed-off-by: Brendan Higgins <brendan.higgins@linux.dev> Signed-off-by: David Gow <davidgow@google.com> Tested-by: Martin Fernandez <martin.fernandez@eclypsium.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-01-31net: ipa: use dev PM wakeirq handlingCaleb Connolly
Replace the enable_irq_wake() call with one to dev_pm_set_wake_irq() instead. This will let the dev PM framework automatically manage the the wakeup capability of the ipa IRQ and ensure that userspace requests to enable/disable wakeup for the IPA via sysfs are respected. Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20230127202758.2913612-1-caleb.connolly@linaro.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31Revert "netfilter: conntrack: fix bug in for_each_sctp_chunk"Florian Westphal
There is no bug. If sch->length == 0, this would result in an infinite loop, but first caller, do_basic_checks(), errors out in this case. After this change, packets with bogus zero-length chunks are no longer detected as invalid, so revert & add comment wrt. 0 length check. Fixes: 98ee00774525 ("netfilter: conntrack: fix bug in for_each_sctp_chunk") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2023-01-31netfilter: br_netfilter: disable sabotage_in hook after first suppressionFlorian Westphal
When using a xfrm interface in a bridged setup (the outgoing device is bridged), the incoming packets in the xfrm interface are only tracked in the outgoing direction. $ brctl show bridge name interfaces br_eth1 eth1 $ conntrack -L tcp 115 SYN_SENT src=192... dst=192... [UNREPLIED] ... If br_netfilter is enabled, the first (encrypted) packet is received onR eth1, conntrack hooks are called from br_netfilter emulation which allocates nf_bridge info for this skb. If the packet is for local machine, skb gets passed up the ip stack. The skb passes through ip prerouting a second time. br_netfilter ip_sabotage_in supresses the re-invocation of the hooks. After this, skb gets decrypted in xfrm layer and appears in network stack a second time (after decryption). Then, ip_sabotage_in is called again and suppresses netfilter hook invocation, even though the bridge layer never called them for the plaintext incarnation of the packet. Free the bridge info after the first suppression to avoid this. I was unable to figure out where the regression comes from, as far as i can see br_netfilter always had this problem; i did not expect that skb is looped again with different headers. Fixes: c4b0e771f906 ("netfilter: avoid using skb->nf_bridge directly") Reported-and-tested-by: Wolfgang Nothdurft <wolfgang@linogate.de> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2023-01-31net: dsa: microchip: ptp: fix up PTP dependencyArnd Bergmann
When NET_DSA_MICROCHIP_KSZ_COMMON is built-in but PTP is a loadable module, the ksz_ptp support still causes a link failure: ld.lld-16: error: undefined symbol: ptp_clock_index >>> referenced by ksz_ptp.c >>> drivers/net/dsa/microchip/ksz_ptp.o:(ksz_get_ts_info) in archive vmlinux.a This can happen if NET_DSA_MICROCHIP_KSZ8863_SMI is enabled, or even if none of the KSZ9477_I2C/KSZ_SPI/KSZ8863_SMI ones are active but only the common module is. The most straightforward way to address this is to move the dependency to NET_DSA_MICROCHIP_KSZ_PTP itself, which can now only be enabled if both PTP_1588_CLOCK support is reachable from NET_DSA_MICROCHIP_KSZ_COMMON. Alternatively, one could make NET_DSA_MICROCHIP_KSZ_COMMON a hidden Kconfig symbol and extend the PTP_1588_CLOCK_OPTIONAL dependency to NET_DSA_MICROCHIP_KSZ8863_SMI as well, but that is a little more fragile. Fixes: eac1ea20261e ("net: dsa: microchip: ptp: add the posix clock support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230130131808.1084796-1-arnd@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31Documentation: networking: correct spellingRandy Dunlap
Correct spelling problems for Documentation/networking/ as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: Jiri Pirko <jiri@nvidia.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20230129231053.20863-5-rdunlap@infradead.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31net: sched: sch: Bounds check priorityKees Cook
Nothing was explicitly bounds checking the priority index used to access clpriop[]. WARN and bail out early if it's pathological. Seen with GCC 13: ../net/sched/sch_htb.c: In function 'htb_activate_prios': ../net/sched/sch_htb.c:437:44: warning: array subscript [0, 31] is outside array bounds of 'struct htb_prio[8]' [-Warray-bounds=] 437 | if (p->inner.clprio[prio].feed.rb_node) | ~~~~~~~~~~~~~~~^~~~~~ ../net/sched/sch_htb.c:131:41: note: while referencing 'clprio' 131 | struct htb_prio clprio[TC_HTB_NUMPRIO]; | ^~~~~~ Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20230127224036.never.561-kees@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31net: ethernet: mtk_eth_soc: Avoid truncating allocationKees Cook
There doesn't appear to be a reason to truncate the allocation used for flow_info, so do a full allocation and remove the unused empty struct. GCC does not like having a reference to an object that has been partially allocated, as bounds checking may become impossible when such an object is passed to other code. Seen with GCC 13: ../drivers/net/ethernet/mediatek/mtk_ppe.c: In function 'mtk_foe_entry_commit_subflow': ../drivers/net/ethernet/mediatek/mtk_ppe.c:623:18: warning: array subscript 'struct mtk_flow_entry[0]' is partly outside array bounds of 'unsigned char[48]' [-Warray-bounds=] 623 | flow_info->l2_data.base_flow = entry; | ^~ Cc: Felix Fietkau <nbd@nbd.name> Cc: John Crispin <john@phrozen.org> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Mark Lee <Mark-MC.Lee@mediatek.com> Cc: Lorenzo Bianconi <lorenzo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230127223853.never.014-kees@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31ibmvnic: Toggle between queue types in affinity mappingNick Child
Previously, ibmvnic IRQs were assigned to CPU numbers by assigning all the IRQs for transmit queues then assigning all the IRQs for receive queues. With multi-threaded processors, in a heavy RX or TX environment, physical cores would either be overloaded or underutilized (due to the IRQ assignment algorithm). This approach is sub-optimal because IRQs for the same subprocess (RX or TX) would be bound to adjacent CPU numbers, meaning they were more likely to be contending for the same core. For example, in a system with 64 CPU's and 32 queues, the IRQs would be bound to CPU in the following pattern: IRQ type | CPU number ----------------------- TX0 | 0-1 TX1 | 2-3 <etc> RX0 | 32-33 RX1 | 34-35 <etc> Observe that in SMT-8, the first 4 tx queues would be sharing the same core. A more optimal algorithm would balance the number RX and TX IRQ's across the physical cores. Therefore, to increase performance, distribute RX and TX IRQs across cores by alternating between assigning IRQs for RX and TX queues to CPUs. With a system with 64 CPUs and 32 queues, this results in the following pattern: IRQ type | CPU number ----------------------- TX0 | 0-1 RX0 | 2-3 TX1 | 4-5 RX1 | 6-7 <etc> Observe that in SMT-8, there is equal distribution of RX and TX IRQs per core. In the above case, each core handles 2 TX and 2 RX IRQ's. Signed-off-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Haren Myneni <haren@linux.ibm.com> Link: https://lore.kernel.org/r/20230127214358.318152-1-nnac123@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-01-31ALSA: firewire-motu: fix unreleased lock warning in hwdep deviceTakashi Sakamoto
Smatch static analysis tool detects that acquired lock is not released in hwdep device when condition branch is passed due to no event. It is unlikely to occur, while fulfilling is preferable for better coding. Reported-by: Dan Carpenter <error27@gmail.com> Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20230130141540.102854-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-01-30Merge tag 'ieee802154-for-net-2023-01-30' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== ieee802154 for net 2023-01-30 Only one fix this time around. Miquel Raynal fixed a potential double free spotted by Dan Carpenter. * tag 'ieee802154-for-net-2023-01-30' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan: mac802154: Fix possible double free upon parsing error ==================== Link: https://lore.kernel.org/r/20230130095646.301448-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30Merge branch 'add-support-for-the-the-vsc7512-internal-copper-phys'Jakub Kicinski
Colin Foster says: ==================== add support for the the vsc7512 internal copper phys This patch series is a continuation to add support for the VSC7512: https://patchwork.kernel.org/project/netdevbpf/list/?series=674168&state=* That series added the framework and initial functionality for the VSC7512 chip. Several of these patches grew during the initial development of the framework, which is why v1 will include changelogs. It was during v9 of that original MFD patch set that these were dropped. With that out of the way, the VSC7512 is mainly a subset of the VSC7514 chip. The 7512 lacks an internal MIPS processor, but otherwise many of the register definitions are identical. That is why several of these patches are simply to expose common resources from drivers/net/ethernet/mscc/*. This patch only adds support for the first four ports (swp0-swp3). The remaining ports require more significant changes to the felix driver, and will be handled in the future. ==================== Link: https://lore.kernel.org/r/20230127193559.1001051-1-colin.foster@in-advantage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30mfd: ocelot: add external ocelot switch controlColin Foster
Utilize the existing ocelot MFD interface to add switch functionality to the Microsemi VSC7512 chip. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Acked-for-MFD-by: Lee Jones <lee@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: dsa: ocelot: add external ocelot switch controlColin Foster
Add control of an external VSC7512 chip. Currently the four copper phy ports are fully functional. Communication to external phys is also functional, but the SGMII / QSGMII interfaces are currently non-functional. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30dt-bindings: mfd: ocelot: add ethernet-switch hardware supportColin Foster
The main purpose of the Ocelot chips are the Ethernet switching functionalities. Document the support for these features. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30dt-bindings: net: mscc,vsc7514-switch: add dsa binding for the vsc7512Colin Foster
The VSC7511, VSC7512, VSC7513 and VSC7514 all have the ability to be controlled either internally by a memory-mapped CPU, or externally via interfaces like SPI and PCIe. The internal CPU of the VSC7511 and 7512 don't have the resources to run Linux, so must be controlled via these external interfaces in a DSA configuration. Add mscc,vsc7512-switch compatible string to indicate that the chips are being controlled externally in a DSA configuration. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30mfd: ocelot: prepend resource size macros to be 32-bitColin Foster
The *_RES_SIZE macros are initally <= 0x100. Future resource sizes will be upwards of 0x200000 in size. To keep things clean, fully align the RES_SIZE macros to 32-bit to do nothing more than make the code more consistent. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Acked-for-MFD-by: Lee Jones <lee@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: dsa: felix: add functionality when not all ports are supportedColin Foster
When the Felix driver would probe the ports and verify functionality, it would fail if it hit single port mode that wasn't supported by the driver. The initial case for the VSC7512 driver will have physical ports that exist, but aren't supported by the driver implementation. Add the OCELOT_PORT_MODE_NONE macro to handle this scenario, and allow the Felix driver to continue with all the ports that are currently functional. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: dsa: felix: add support for MFD configurationsColin Foster
The architecture around the VSC7512 differs from existing felix drivers. In order to add support for all the chip's features (pinctrl, MDIO, gpio) the device had to be laid out as a multi-function device (MFD). One difference between an MFD and a standard platform device is that the regmaps are allocated to the parent device before the child devices are probed. As such, there is no need for felix to initialize new regmaps in these configurations, they can simply be requested from the parent device. Add support for MFD configurations by performing this request from the parent device. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: dsa: felix: add configurable device quirksColin Foster
The define FELIX_MAC_QUIRKS was used directly in the felix.c shared driver. Other devices (VSC7512 for example) don't require the same quirks, so they need to be configured on a per-device basis. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: mscc: ocelot: expose vsc7514_regmap definitionColin Foster
The VSC7514 target regmap is identical for ones shared with similar hardware, specifically the VSC7512. Share this resource, and change the name to match the pattern of other exported resources. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: mscc: ocelot: expose ocelot_reset routineColin Foster
Resetting the switch core is the same whether it is done internally or externally. Move this routine to the ocelot library so it can be used by other drivers. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: mscc: ocelot: expose vcap_props structureColin Foster
The vcap_props structure is common to other devices, specifically the VSC7512 chip that can only be controlled externally. Export this structure so it doesn't need to be recreated. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: mscc: ocelot: expose regfield definition to be used by other driversColin Foster
The ocelot_regfields struct is common between several different chips, some of which can only be controlled externally. Export this structure so it doesn't have to be duplicated in these other drivers. Rename the structure as well, to follow the conventions of other shared resources. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: mscc: ocelot: expose ocelot wm functionsColin Foster
Expose ocelot_wm functions so they can be shared with other drivers. Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # regression Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net/tls: tls_is_tx_ready() checked list_entryPietro Borrello
tls_is_tx_ready() checks that list_first_entry() does not return NULL. This condition can never happen. For empty lists, list_first_entry() returns the list_entry() of the head, which is a type confusion. Use list_first_entry_or_null() which returns NULL in case of empty lists. Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Link: https://lore.kernel.org/r/20230128-list-entry-null-check-tls-v1-1-525bbfe6f0d0@diag.uniroma1.it Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: phy: motorcomm: change the phy id of yt8521 and yt8531s to lowercaseFrank Sae
The phy id is usually defined in lower case. Signed-off-by: Frank Sae <Frank.Sae@motor-comm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230128063558.5850-2-Frank.Sae@motor-comm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: phy: fix the spelling problem of SentinelFrank Sae
CHECK: 'sentinal' may be misspelled - perhaps 'sentinel'? Signed-off-by: Frank Sae <Frank.Sae@motor-comm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230128063558.5850-1-Frank.Sae@motor-comm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30sh: checksum: add missing linux/uaccess.h includeJakub Kicinski
SuperH does not include uaccess.h, even tho it calls access_ok(). Fixes: 68f4eae781dd ("net: checksum: drop the linux/uaccess.h include") Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230128073108.1603095-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net: b44: Remove the unused function __b44_cam_read()Jiapeng Chong
The function __b44_cam_read() is defined in the b44.c file, but not called elsewhere, so remove this unused function. drivers/net/ethernet/broadcom/b44.c:199:20: warning: unused function '__b44_cam_read'. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3858 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230128090413.79824-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-01-27 (ice) This series contains updates to ice driver only. Dave prevents modifying channels when RDMA is active as this will break RDMA traffic. Michal fixes a broken URL. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: Fix broken link in ice NAPI doc ice: Prevent set_channel from changing queues while RDMA active ==================== Link: https://lore.kernel.org/r/20230127225333.1534783-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30net/mlx5e: kTLS, Improve connection rate by using fast update encryption keyJianbo Liu
As the fast DEK update is fully implemented, use it for kTLS to get better performance. TIS pool was already supported to recycle the TISes. With this series and TIS pool, TLS CPS is improved by 9x higher, from 11k/s to 101k/s. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Keep only one bulk of full available DEKsJianbo Liu
One bulk with full available keys is left undestroyed, to service the possible requests from users quickly. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Add async garbage collector for DEK bulkJianbo Liu
After invalidation, the idle bulk with all DEKs available for use, is destroyed, to free keys and mem. To get better performance, the firmware destruction operation is done asynchronously. So idle bulks are enqueued in destroy_list first, then destroyed in system workqueue. This will improve performance, as the destruction doesn't need to hold pool's mutex. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Reuse DEKs after executing SYNC_CRYPTO commandJianbo Liu
To fast update encryption keys, those freed keys with need_sync bit 1 and in_use bit 0 in a bulk, can be recycled. The keys are cached internally by the NIC, so invalidating internal NIC caches by SYNC_CRYPTO command is required before reusing them. A threshold in driver is added to avoid invalidating for every update. Only when the number of DEKs, which need to be synced, is over this threshold, the sync process will start. Besides, it is done in system workqueue. After SYNC_CRYPTO command is executed successfully, the bitmaps of each bulk must be reset accordingly, so that the freed DEKs can be reused. From the analysis in previous patch, the number of reused DEKs can be calculated by hweight_long(need_sync XOR in_use), and the need_sync bits can be reset by simply copying from in_use bits. Two more list (avail_list and sync_list) are added for each pool. The avail_list is for a bulk when all bits in need_sync are reset after sync. If there is no avail deks, and all are be freed by users, the bulk is moved to sync_list, instead of being destroyed in previous patch, and waiting for the invalidation. While syncing, they are simply reset need_sync bits, and moved to avail_list. Besides, add a wait_for_free list for the to-be-free DEKs. It is to avoid this corner case: when thread A is done with SYNC_CRYPTO but just before starting to reset the bitmaps, thread B is alloc dek, and free it immediately. It's obvious that this DEK can't be reused this time, so put it to waiting list, and do free after bulk bitmaps reset is finished. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Use bulk allocation for fast update encryption keyJianbo Liu
We create a pool for each key type. For the pool, there is a struct to store the info for all DEK objects of one bulk allocation. As we use crypto->log_dek_obj_range, which is set to 12 in previous patch, for the log_obj_range of bulk allocation, 4096 DEKs are allocated in one time. To trace the state of all the keys in a bulk, two bitmaps are created. The need_sync bitmap is used to indicate the available state of the corresponding key. If the bit is 0, it can be used (available) as it either is newly created by FW, or SYNC_CRYPTO is executed and bit is reset after it is freed by upper layer user (this is the case to be handled in later patch). Otherwise, the key need to be synced. The in_use bitmap is used to indicate the key is being used, and reset when user free it. When ktls, ipsec or macsec need a key from a bulk, it get one with need_sync bit 0, then set both need_sync and in_used bit to 1. When user free a key, only in_use bit is reset to 0. So, for the combinations of (need_sync, in_use) of one DEK object, - (0,0) means the key is ready for use, - (1,1) means the key is currently being used by a user, - (1,0) means the key is freed, and waiting for being synced, - (0,1) is invalid state. There are two lists in each pool, partial_list and full_list, according to the number for available DEKs in a bulk. When user need a key, it get a bulk, either from partial list, or create new one from FW. Then the bulk is put in the different pool's lists according to the num of avail deks it has. If there is no avail deks, and all of them are be freed by users, for now, the bulk is destroyed. To speed up the bitmap search, a variable (avail_start) is added to indicate where to start to search need_sync bitmap for available key. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Add bulk allocation and modify_dek operationJianbo Liu
To support fast update of keys into hardware, we optimize firmware to achieve the maximum rate. The approach is to create DEK objects in bulk, and update each of them with modify command. This patch supports bulk allocation and modify_dek commands for new firmware. However, as log_obj_range is 0 for now, only one DEK obj is allocated each time, and then updated with user key by modify_dek. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Add support SYNC_CRYPTO commandJianbo Liu
Add support for SYNC_CRYPTO command. For now, it is executed only when initializing DEK, but needed when reusing keys in later patch. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Add new APIs for fast update encryption keyJianbo Liu
New APIs are added to support fast update DEKs. As a pool is created for each key purpose (type), one pair of pool APIs to get/put pool. Anotehr pair of DEKs APIs is to get DEK object from pool and update it with user key, or free it back to the pool. As The bulk allocation and destruction will be supported in later patches, old implementation is used here. To support these APIs, pool and dek structs are defined first. Only small number of fields are stored in them. For example, key_purpose and refcnt in pool struct, DEK object id in dek struct. More fields will be added to these structs in later patches, for example, the different bulk lists for pool struct, the bulk pointer dek struct belongs to, and a list_entry for the list in a pool, which is used to save keys waiting for being freed while other thread is doing sync. Besides the creation and destruction interfaces, new one is also added to get obj id. Currently these APIs are planned to used by TLS only. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-01-30net/mlx5: Refactor the encryption key creationJianbo Liu
Move the common code to general functions which can be used by fast update encryption key in later patches. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-31 00:11:41 +0000