- 18 Jan, 2023 18 commits
-
-
Florian Westphal authored
Those are all useless or dubious. getorigdst() is called via setsockopt, so return value/errno will already indicate an appropriate error. For other pr_debug calls there are better replacements, such as slab/slub debugging or 'conntrack -E' (ctnetlink events). Signed-off-by:Florian Westphal <fw@strlen.de>
-
Florian Westphal authored
The conntrack logging facilities include useful info such as in/out interface names and packet headers. Use those in more places instead of pr_debug calls. Furthermore, several pr_debug calls can be removed, they are useless on production machines due to the sheer volume of log messages. Signed-off-by: -
Jakub Kicinski authored
Michael Walle says: ==================== net: mdio: Continue separating C22 and C45 I've picked this older series from Andrew up and rebased it onto the latest net-next. This is the third (and hopefully last) patch set in the series which separates the C22 and C45 MDIO bus transactions at the API level to the MDIO bus drivers. The first patch is a newer version of the former "net: dsa: Separate C22 and C45 MDIO bus transaction methods", which only contains the mt7530 changes. Although posted as v1, because this is a new series, there is a changelog included in the patch comment section. The last patch is a new one, which isn't from Andrew's tree. ==================== Link: https://lore.kernel.org/r/20230116-net-next-c45-seperation-part-3-v1-0-0c53afa56aad@walle.ccSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Michael Walle authored
The rswitch MDIO bus driver only supports C45 transfers. Update the function names to make this clear, pass the mmd as a parameter, and register the accessors to the _c45 ops of the bus driver structure. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Andrew Lunn authored
The T1 MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
The sja1105 MDIO bus driver only supports C45 transfers. Update the function names to make this clear, pass the mmd as a parameter, and register the accessors to the _c45 ops of the bus driver structure. Signed-off-by:
-
Andrew Lunn authored
The xgbe driver reuses MII_ADDR_C45 for its own purpose. The values derived with it are never passed to phylib or a linux MDIO bus driver. In order that MII_ADDR_C45 can be removed, add an XGBE specific Signed-off-by:
-
Andrew Lunn authored
The xgbe MDIO bus driver can perform both C22 and C45 transfers, when using its MDIO bus hardware. The SFP I2C mdio bus driver only supports C22. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The hns MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
When performing a C45 bus transaction, make use of the c45 variants of the bus read/write helpers. The ability to pass a special register value is being removed to clean up the mdio bus driver API. Signed-off-by:
-
Andrew Lunn authored
The ixgbe MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The macb MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The nixge MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
The sxgdb MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
-
Andrew Lunn authored
mt7530 does support C45, but its uses a mix of registering its MDIO bus and providing its private MDIO bus to the DSA core, too. This makes the change a bit more complex. Signed-off-by:
-
Mengyuan Lou authored
Convert various mult-bit fields to be defined using GENMASK/FIELD_PREP. Simplify the code with the ternary operator. Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230116103839.84087-1-mengyuanlou@net-swift.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxJakub Kicinski authored
Wolfram Sang says: ==================== Immutable branch adding fwnode API to the I2C core I2C changes requested by Russell King. This allows him to rework SFP code further. * tag 'i2c-fwnode-api-2023017' of https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: add fwnode APIs ==================== Link: https://lore.kernel.org/r/Y8ZhI4g0wsvpjokd@ninjato/Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Mark Brown says: ==================== regmap: Rework regmap_mdio_c45_{read|write} for new C45 API. This reworks the regmap MDIO handling of C45 addresses in preparation for some forthcoming updates to the networking code. * tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Rework regmap_mdio_c45_{read|write} for new C45 API. ==================== Link: https://lore.kernel.org/r/Y8VjkgcWHjR9TzNw@sirena.org.ukSigned-off-by:
-
- 17 Jan, 2023 14 commits
-
-
Andrew Lunn authored
The recent refactoring to split C22 and C45 introduced two unneeded semiconons which the kernel test bot reported. Remove them. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 93641ecb ("net: mdio: cavium: Separate C22 and C45 transactions") Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Pietro Borrello authored
__inet_hash_connect() has a fast path taken if sk_head(&tb->owners) is equal to the sk parameter. sk_head() returns the hlist_entry() with respect to the sk_node field. However entries in the tb->owners list are inserted with respect to the sk_bind_node field with sk_add_bind_node(). Thus the check would never pass and the fast path never execute. This fast path has never been executed or tested as this bug seems to be present since commit 1da177e4 ("Linux-2.6.12-rc2"), thus remove it to reduce code complexity. Signed-off-by:
Pietro Borrello <borrello@diag.uniroma1.it> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230112-inet_hash_connect_bind_head-v3-1-b591fd212b93@diag.uniroma1.itSigned-off-by:
-
Paolo Abeni authored
Lorenzo Bianconi says: ==================== net: ethernet: mtk_wed: introduce reset support Introduce proper reset integration between ethernet and wlan drivers in order to schedule wlan driver reset when ethernet/wed driver is resetting. Introduce mtk_hw_reset_monitor work in order to detect possible DMA hangs. ==================== Link: https://lore.kernel.org/r/cover.1673715298.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Introduce reset and reset_complete wlan callback to schedule WLAN driver reset when ethernet/wed driver is resetting. Tested-by:
Daniel Golle <daniel@makrotopia.org> Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mtk_hw_check_dma_hang routine to monitor possible dma hangs. Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Tested-by:
-
Lorenzo Bianconi authored
Avoid to power-down the ethernet chip during hw reset and align reset procedure to vendor sdk. Reviewed-by:
-
Lorenzo Bianconi authored
Introduce mtk_hw_warm_reset utility routine. This is a preliminary patch to align reset procedure to vendor sdk and avoid to power down the chip during hw reset. Reviewed-by:
-
Lorenzo Bianconi authored
This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Reviewed-by:
-
Paolo Abeni authored
Jesper Dangaard Brouer says: ==================== net: use kmem_cache_free_bulk in kfree_skb_list The kfree_skb_list function walks SKB (via skb->next) and frees them individually to the SLUB/SLAB allocator (kmem_cache). It is more efficient to bulk free them via the kmem_cache_free_bulk API. Netstack NAPI fastpath already uses kmem_cache bulk alloc and free APIs for SKBs. The kfree_skb_list call got an interesting optimization in commit 520ac30f ("net_sched: drop packets after root qdisc lock is released") that can create a list of SKBs "to_free" e.g. when qdisc enqueue fails or deliberately chooses to drop . It isn't a normal data fastpath, but the situation will likely occur when system/qdisc are under heavy workloads, thus it makes sense to use a faster API for freeing the SKBs. E.g. the (often distro default) qdisc fq_codel will drop batches of packets from fattest elephant flow, default capped at 64 packets (but adjustable via tc argument drop_batch). Performance measurements done in [1]: [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org ==================== Link: https://lore.kernel.org/r/167361788585.531803.686364041841425360.stgit@firesoulSigned-off-by:
-
Jesper Dangaard Brouer authored
The kfree_skb_list function walks SKB (via skb->next) and frees them individually to the SLUB/SLAB allocator (kmem_cache). It is more efficient to bulk free them via the kmem_cache_free_bulk API. This patches create a stack local array with SKBs to bulk free while walking the list. Bulk array size is limited to 16 SKBs to trade off stack usage and efficiency. The SLUB kmem_cache "skbuff_head_cache" uses objsize 256 bytes usually in an order-1 page 8192 bytes that is 32 objects per slab (can vary on archs and due to SLUB sharing). Thus, for SLUB the optimal bulk free case is 32 objects belonging to same slab, but runtime this isn't likely to occur. The expected gain from using kmem_cache bulk alloc and free API have been assessed via a microbencmark kernel module[1]. The module 'slab_bulk_test01' results at bulk 16 element: kmem-in-loop Per elem: 109 cycles(tsc) 30.532 ns (step:16) kmem-bulk Per elem: 64 cycles(tsc) 17.905 ns (step:16) More detailed description of benchmarks avail in [2]. [1] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm [2] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org V2: rename function to kfree_skb_add_bulk. Reviewed-by:
Saeed Mahameed <saeed@kernel.org> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Jesper Dangaard Brouer authored
The SKB drop reason uses __builtin_return_address(0) to give the call "location" to trace_kfree_skb() tracepoint skb:kfree_skb. To keep this stable for compilers kfree_skb_reason() is annotated with __fix_address (noinline __noclone) as fixed in commit c205cc75 ("net: skb: prevent the split of kfree_skb_reason() by gcc"). The function kfree_skb_list_reason() invoke kfree_skb_reason(), which cause the __builtin_return_address(0) "location" to report the unexpected address of kfree_skb_list_reason. Example output from 'perf script': kpktgend_0 1337 [000] 81.002597: skb:kfree_skb: skbaddr=0xffff888144824700 protocol=2048 location=kfree_skb_list_reason+0x1e reason: QDISC_DROP Patch creates an __always_inline __kfree_skb_reason() helper call that is called from both kfree_skb_list() and kfree_skb_list_reason(). Suggestions for solutions that shares code better are welcome. As preparation for next patch move __kfree_skb() invocation out of this helper function. Reviewed-by:
-
Dan Carpenter authored
This code checks if (attrs[DEVLINK_ATTR_TRAP_POLICER_ID]) twice. Once at the start of the function and then a couple lines later. Delete the second check since that one must be true. Because the second condition is always true, it means the: policer_item = group_item->policer_item; assignment is immediately over-written. Delete that as well. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Acked-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/Y8EJz8oxpMhfiPUb@kiliSigned-off-by:
-
Hangbin Liu authored
We will report extack message if there is an error via netlink_ack(). But if the rule is not to be exclusively executed by the hardware, extack is not passed along and offloading failures don't get logged. In commit 81c7288b ("sched: cls: enable verbose logging") Marcelo made cls could log verbose info for offloading failures, which helps improving Open vSwitch debuggability when using flower offloading. It would also be helpful if userspace monitor tools, like "tc monitor", could log this kind of message, as it doesn't require vswitchd log level adjusment. Let's add a new tc attributes to report the extack message so the monitor program could receive the failures. e.g. # tc monitor added chain dev enp3s0f1np1 parent ffff: chain 0 added filter dev enp3s0f1np1 ingress protocol all pref 49152 flower chain 0 handle 0x1 ct_state +trk+new not_in_hw action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 Warning: mlx5_core: matching on ct_state +new isn't supported. In this patch I only report the extack message on add/del operations. It doesn't look like we need to report the extack message on get/dump operations. Note this message not only reporte to multicast groups, it could also be reported unicast, which may affect the current usersapce tool's behaivor. Suggested-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20230113034353.2766735-1-liuhangbin@gmail.comSigned-off-by:
-
Russell King (Oracle) authored
Add fwnode APIs for finding and getting I2C adapters, which will be used by the SFP code. These are passed the fwnode corresponding to the adapter, and return the I2C adapter. It is the responsibility of the caller to find the appropriate fwnode. We keep the DT and ACPI interfaces, but where appropriate, recode them to use the fwnode interfaces internally. Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
- 16 Jan, 2023 8 commits
-
-
David S. Miller authored
Colin Foster says ==================== dt-binding preparation for ocelot switches Ocelot switches have the abilitiy to be used internally via memory-mapped IO or externally via SPI or PCIe. This brings up issues for documentation, where the same chip might be accessed internally in a switchdev manner, or externally in a DSA configuration. This patch set is perparation to bring DSA functionality to the VSC7512, utilizing as much as possible with an almost identical VSC7514 chip. This patch set changed quite a bit from v2, so I'll omit the background of how those sets came to be. Rob offered a lot of very useful guidance. My thanks. At the end of the day, with this patch set, there should be a framework to document Ocelot switches (and any switch) in scenarios where they can be controlled internally (ethernet-switch) or externally (dsa-switch). --- v6 -> v7 * Add Reviewed / Acked on patch 1 * Clean up descriptions on Ethernet / DSA switch port bindings v5 -> v6 * Rebase so it applies to net-next cleanly. * No other changes - during the last submission round I said I'd submit v6 with a change to move $dsa-port.yaml to outside the allOf list. In retrospect that wasn't the right thing to do, because later in the patch series the $dsa-port.yaml is removed outright. So I believe the submission in v5 to keep "type: object" was correct. v4 -> v5 * Sync DSA maintainers with MAINTAINERS file (new patch 1) * Undo move of port description of mediatek,mt7530.yaml (patch 4) * Move removal of "^(ethernet-)?switch(@.*)?$" in dsa.yaml from patch 4 to patch 8 * Add more consistent capitalization in title lines and better Ethernet switch port description. (patch 8) v3 -> v4 * Renamed "base" to "ethernet-ports" to avoid confusion with the concept of a base class. * Squash ("dt-bindings: net: dsa: mediatek,mt7530: fix port description location") patch into ("dt-bindings: net: dsa: utilize base definitions for standard dsa switches") * Corrections to fix confusion about additonalProperties vs unevaluatedProperties. See specific patches for details. v2 -> v3 * Restructured everything to use a "base" iref for devices that don't have additional properties, and simply a "ref" for devices that do. * New patches to fix up brcm,sf2, qca8k, and mt7530 * Fix unevaluatedProperties errors from previous sets (see specific patches for more detail) * Removed redundant "Device Tree Binding" from titles, where applicable. v1 -> v2 * Two MFD patches were brought into the MFD tree, so are dropped * Add first patch 1/6 to allow DSA devices to add ports and port properties * Test qca8k against new dt-bindings and fix warnings. (patch 2/6) * Add tags (patch 3/6) * Fix vsc7514 refs and properties ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Colin Foster authored
Several bindings for ethernet switches are available for non-dsa switches by way of ethernet-switch.yaml. Remove these duplicate entries and utilize the common bindings for the VSC7514. Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Colin Foster authored
The dsa-port.yaml binding had several references that can be common to all ethernet ports, not just dsa-specific ones. Break out the generic bindings to ethernet-switch-port.yaml they can be used by non-dsa drivers. Signed-off-by:
-
Colin Foster authored
The dsa.yaml bindings had references that can apply to non-dsa switches. To prevent duplication of this information, keep the dsa-specific information inside dsa.yaml and move the remaining generic information to the newly created ethernet-switch.yaml. Signed-off-by:
-
Colin Foster authored
dsa.yaml contains a reference to dsa-port.yaml, so a duplicate reference to the binding isn't necessary. Remove this unnecessary reference. Signed-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by:
-
Colin Foster authored
The dsa.yaml binding contains duplicated bindings for address and size cells, as well as the reference to dsa-port.yaml. Instead of duplicating this information, remove the reference to dsa-port.yaml and include the full reference to dsa.yaml. Signed-off-by:
-
Colin Foster authored
Explicitly allow additional properties for both the ethernet-port and ethernet-ports properties. This specifically will allow the qca8k.yaml binding to use shared properties. Signed-off-by:
-
Colin Foster authored
DSA switches can fall into one of two categories: switches where all ports follow standard '(ethernet-)?port' properties, and switches that have additional properties for the ports. The scenario where DSA ports are all standardized can be handled by switches with a reference to the new 'dsa.yaml#/$defs/ethernet-ports'. The scenario where DSA ports require additional properties can reference '$dsa.yaml#' directly. This will allow switches to reference these standard definitions of the DSA switch, but add additional properties under the port nodes. Suggested-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
