- 18 Jan, 2023 4 commits
-
-
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:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
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 22 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:
-
Colin Foster authored
The children of the switch node don't have a unit address, and therefore should not need the #address-cells or #size-cells entries. Fix the example schemas accordingly. Suggested-by:
-
Colin Foster authored
The property use-bcm-hdr was documented as an entry under the ports node for the bcm_sf2 DSA switch. This property is actually evaluated for each port. Correct the documentation to match the actual behavior and properly reference dsa-port.yaml for additional properties of the node. Suggested-by:
-
Colin Foster authored
The MAINTAINERS file has Andrew Lunn, Florian Fainelli, and Vladimir Oltean listed as the maintainers for generic dsa bindings. Update dsa.yaml and dsa-port.yaml accordingly. Signed-off-by:
-
David S. Miller authored
Steen Hegelund says: ==================== net: microchip: Add support for two classes of VCAP rules This adds support for two classes of VCAP rules: - Permanent rules (added e.g. for PTP support) - TC user rules (added by the TC userspace tool) For this to work the VCAP Loopups must be enabled from boot, so that the "internal" clients like PTP can add rules that are always active. When the TC tool add a flower filter the VCAP rule corresponding to this filter will be disabled (kept in memory) until a TC matchall filter creates a link from chain 0 to the chain (lookup) where the flower filter was added. When the flower filter is enabled it will be written to the appropriate VCAP lookup and become active in HW. Likewise the flower filter will be disabled if there is no link from chain 0 to the chain of the filter (lookup), and when that happens the corresponding VCAP rule will be read from the VCAP instance and stored in memory until it is deleted or enabled again. Version History: ================ v4 Removed a leftover 'Fixes' tag from v2. No functional changes. v3 Removed the change that allowed rules to always be added in the LAN996x even though the lookups are not enabled (Horatiu Vultur). This was sent separately to net instead. Removed the 'Fixes' tags due to the patch sent to net by Horatiu Vultur. Added a check for validity of the chain source when enabling a lookup. v2 Adding a missing goto exit in vcap_add_rule (Dan Carpenter). Added missing checks for error returns in vcap_enable_rule. v1 Initial version ==================== Signed-off-by: -
Steen Hegelund authored
This supports that individual rules are enabled and disabled via chain information. This is done by keeping disabled rules in the VCAP list (cached) until they are enabled, and only at this time are the rules written to the VCAP HW. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
-
Steen Hegelund authored
This allows a VCAP rule to be in one of 3 states: - permanently stored in the VCAP HW (for rules that must always be present) - enabled (stored in HW) when the corresponding lookup has been enabled - disabled (stored in SW) when the lookup is disabled This way important VCAP rules can be added even before the user enables the VCAP lookups using a TC matchall filter. Signed-off-by:
-
Steen Hegelund authored
This changes the way the chain information verified when adding a new tc flower filter. When adding a flower filter it is now checked that the filter contains a goto action to one of the IS2 VCAP lookups, except for the last lookup which may omit this goto action. It is also checked if you attempt to add multiple matchall filters to enable the same VCAP lookup. This will be rejected. Signed-off-by:
-
Steen Hegelund authored
This adds both the source and destination chain id to the information kept for enabled port lookups. This allows enabling and disabling a chain of lookups by walking the chain information for a port. This changes the way that VCAP lookups are enabled from userspace: instead of one matchall rule that enables all the 4 Sparx5 IS2 lookups, you need a matchall rule per lookup. In practice that is done by adding one matchall rule in chain 0 to goto IS2 Lookup 0, and then for each lookup you add a rule per lookup (low priority) that does a goto to the next lookup chain. Examples: If you want IS2 Lookup 0 to be enabled you add the same matchall filter as before: tc filter add dev eth12 ingress chain 0 prio 1000 handle 1000 matchall \ skip_sw action goto chain 8000000 If you also want to enable lookup 1 to 3 in IS2 and chain them you need to add the following matchall filters: tc filter add dev eth12 ingress chain 8000000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8100000 tc filter add dev eth12 ingress chain 8100000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8200000 tc filter add dev eth12 ingress chain 8200000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8300000 Signed-off-by: -
Steen Hegelund authored
The conversion to the platform specific multi-word format is moved from the key/action add functions to the encoding key/action. This allows rules that are disabled (not in VCAP HW) to use the same format for keys/actions as rules that have just been read from VCAP HW. Signed-off-by:
-
Steen Hegelund authored
This changes the VCAP lookups state to always be enabled so that it is possible to add "internal" VCAP rules that must be available even though the user has not yet enabled the VCAP chains via a TC matchall filter. The API callback to enable and disable VCAP lookups is therefore removed. Signed-off-by:
-
Steen Hegelund authored
When a rule counter is external to the VCAP such as the Sparx5 IS2 counters are, then this counter must be reset when a new rule is created. Signed-off-by:
-
Steen Hegelund authored
For consistency the VCAP cache area is erased just before the new rule is being encoded. Signed-off-by:
-
Heiner Kallweit authored
ASPM issues may result in the NIC not being accessible any longer. In this case disabling ASPM may not work. Therefore detect this case by checking whether register reads return ~0, and try to make the NIC accessible again by resetting the secondary bus. v2: - add exception handling for the case that pci_reset_bus() fails Suggested-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
-
Kurt Kanzenbach authored
The switch receives management traffic such as STP and LLDP. However, PTP messages are not received, only transmitted. Ideally, the switch would trap all PTP messages to the management CPU. This particular switch has a PTP block which identifies PTP messages and traps them to a dedicated port. There is a register to program this destination. This is not used at the moment. Therefore, program it to the same port as the MGMT traffic is trapped to. This allows to receive PTP messages as soon as timestamping is enabled. In addition, the datasheet mentions that this register is not valid e.g., for 6190 variants. So, add a new PTP operation which is added for the 6390 and 6290 devices. Tested simply like this on Marvell 88E6390, revision 1: |/ # ptp4l -2 -i lan4 --tx_timestamp_timeout=40 -m |[...] |ptp4l[147.450]: master offset 56 s2 freq +1262 path delay 413 |ptp4l[148.450]: master offset 22 s2 freq +1244 path delay 434 |ptp4l[149.450]: master offset 5 s2 freq +1234 path delay 446 |ptp4l[150.451]: master offset 3 s2 freq +1233 path delay 451 |ptp4l[151.451]: master offset 1 s2 freq +1232 path delay 451 |ptp4l[152.451]: master offset -3 s2 freq +1229 path delay 451 |ptp4l[153.451]: master offset 9 s2 freq +1240 path delay 451 Link: https://lore.kernel.org/r/CAFSKS=PJBpvtRJxrR4sG1hyxpnUnQpiHg4SrUNzAhkWnyt9ivg@mail.gmail.comSigned-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
-
