- 20 Aug, 2024 13 commits
-
-
Paolo Abeni authored
Ido Schimmel says: ==================== Preparations for FIB rule DSCP selector This patchset moves the masking of the upper DSCP bits in 'flowi4_tos' to the core instead of relying on callers of the FIB lookup API to do it. This will allow us to start changing users of the API to initialize the 'flowi4_tos' field with all six bits of the DSCP field. In turn, this will allow us to extend FIB rules with a new DSCP selector. By masking the upper DSCP bits in the core we are able to maintain the behavior of the TOS selector in FIB rules and routes to only match on the lower DSCP bits. While working on this I found two users of the API that do not mask the upper DSCP bits before performing the lookup. The first is an ancient netlink family that is unlikely to be used. It is adjusted in patch #1 to mask both the upper DSCP bits and the ECN bits before calling the API. The second user is a nftables module that differs in this regard from its equivalent iptables module. It is adjusted in patch #2 to invoke the API with the upper DSCP bits masked, like all other callers. The relevant selftest passed, but in the unlikely case that regressions are reported because of this change, we can restore the existing behavior using a new flow information flag as discussed here [1]. The last patch moves the masking of the upper DSCP bits to the core, making the first two patches redundant, but I wanted to post them separately to call attention to the behavior change for these two users of the FIB lookup API. Future patchsets (around 3) will start unmasking the upper DSCP bits throughout the networking stack before adding support for the new FIB rule DSCP selector. Changes from v1 [2]: Patch #3: Include <linux/ip.h> in <linux/in_route.h> instead of including it in net/ip_fib.h [1] https://lore.kernel.org/netdev/ZpqpB8vJU%2FQ6LSqa@debian/ [2] https://lore.kernel.org/netdev/20240725131729.1729103-1-idosch@nvidia.com/ ==================== Link: https://patch.msgid.link/20240814125224.972815-1-idosch@nvidia.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Ido Schimmel authored
The TOS field in the IPv4 flow information structure ('flowi4_tos') is matched by the kernel against the TOS selector in IPv4 rules and routes. The field is initialized differently by different call sites. Some treat it as DSCP (RFC 2474) and initialize all six DSCP bits, some treat it as RFC 1349 TOS and initialize it using RT_TOS() and some treat it as RFC 791 TOS and initialize it using IPTOS_RT_MASK. What is common to all these call sites is that they all initialize the lower three DSCP bits, which fits the TOS definition in the initial IPv4 specification (RFC 791). Therefore, the kernel only allows configuring IPv4 FIB rules that match on the lower three DSCP bits which are always guaranteed to be initialized by all call sites: # ip -4 rule add tos 0x1c table 100 # ip -4 rule add tos 0x3c table 100 Error: Invalid tos. While this works, it is unlikely to be very useful. RFC 791 that initially defined the TOS and IP precedence fields was updated by RFC 2474 over twenty five years ago where these fields were replaced by a single six bits DSCP field. Extending FIB rules to match on DSCP can be done by adding a new DSCP selector while maintaining the existing semantics of the TOS selector for applications that rely on that. A prerequisite for allowing FIB rules to match on DSCP is to adjust all the call sites to initialize the high order DSCP bits and remove their masking along the path to the core where the field is matched on. However, making this change alone will result in a behavior change. For example, a forwarded IPv4 packet with a DS field of 0xfc will no longer match a FIB rule that was configured with 'tos 0x1c'. This behavior change can be avoided by masking the upper three DSCP bits in 'flowi4_tos' before comparing it against the TOS selectors in FIB rules and routes. Implement the above by adding a new function that checks whether a given DSCP value matches the one specified in the IPv4 flow information structure and invoke it from the three places that currently match on 'flowi4_tos'. Use RT_TOS() for the masking of 'flowi4_tos' instead of IPTOS_RT_MASK since the latter is not uAPI and we should be able to remove it at some point. Include <linux/ip.h> in <linux/in_route.h> since the former defines IPTOS_TOS_MASK which is used in the definition of RT_TOS() in <linux/in_route.h>. No regressions in FIB tests: # ./fib_tests.sh [...] Tests passed: 218 Tests failed: 0 And FIB rule tests: # ./fib_rule_tests.sh [...] Tests passed: 116 Tests failed: 0 Signed-off-by:Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
As part of its functionality, the nftables FIB expression module performs a FIB lookup, but unlike other users of the FIB lookup API, it does so without masking the upper DSCP bits. In particular, this differs from the equivalent iptables match ("rpfilter") that does mask the upper DSCP bits before the FIB lookup. Align the module to other users of the FIB lookup API and mask the upper DSCP bits using IPTOS_RT_MASK before the lookup. No regressions in nft_fib.sh: # ./nft_fib.sh PASS: fib expression did not cause unwanted packet drops PASS: fib expression did drop packets for 1.1.1.1 PASS: fib expression did drop packets for 1c3::c01d PASS: fib expression forward check with policy based routing Signed-off-by:Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Ido Schimmel authored
The NETLINK_FIB_LOOKUP netlink family can be used to perform a FIB lookup according to user provided parameters and communicate the result back to user space. However, unlike other users of the FIB lookup API, the upper DSCP bits and the ECN bits of the DS field are not masked, which can result in the wrong result being returned. Solve this by masking the upper DSCP bits and the ECN bits using IPTOS_RT_MASK. The structure that communicates the request and the response is not exported to user space, so it is unlikely that this netlink family is actually in use [1]. [1] https://lore.kernel.org/netdev/ZpqpB8vJU%2FQ6LSqa@debian/Signed-off-by:
-
Paolo Abeni authored
Wen Gu says: ==================== net/smc: introduce ringbufs usage statistics Currently, we have histograms that show the sizes of ringbufs that ever used by SMC connections. However, they are always incremental and since SMC allows the reuse of ringbufs, we cannot know the actual amount of ringbufs being allocated or actively used. So this patch set introduces statistics for the amount of ringbufs that actually allocated by link group and actively used by connections of a certain net namespace, so that we can react based on these memory usage information, e.g. active fallback to TCP. With appropriate adaptations of smc-tools, we can obtain these ringbufs usage information: $ smcr -d linkgroup LG-ID : 00000500 LG-Role : SERV LG-Type : ASYML VLAN : 0 PNET-ID : Version : 1 Conns : 0 Sndbuf : 12910592 B <- RMB : 12910592 B <- or $ smcr -d stats [...] RX Stats Data transmitted (Bytes) 869225943 (869.2M) Total requests 18494479 Buffer usage (Bytes) 12910592 (12.31M) <- [...] TX Stats Data transmitted (Bytes) 12760884405 (12.76G) Total requests 36988338 Buffer usage (Bytes) 12910592 (12.31M) <- [...] [...] Change log: v3->v2 - use new helper nla_put_uint() instead of nla_put_u64_64bit(). v2->v1 https://lore.kernel.org/r/20240807075939.57882-1-guwen@linux.alibaba.com/ - remove inline keyword in .c files. - use local variable in macros to avoid potential side effects. v1 https://lore.kernel.org/r/20240805090551.80786-1-guwen@linux.alibaba.com/ ==================== Link: https://patch.msgid.link/20240814130827.73321-1-guwen@linux.alibaba.comSigned-off-by:
-
Wen Gu authored
The buffer size histograms in smc_stats, namely rx/tx_rmbsize, record the sizes of ringbufs for all connections that have ever appeared in the net namespace. They are incremental and we cannot know the actual ringbufs usage from these. So here introduces statistics for current ringbufs usage of existing smc connections in the net namespace into smc_stats, it will be incremented when new connection uses a ringbuf and decremented when the ringbuf is unused. Signed-off-by:
Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
-
Wen Gu authored
Currently we have the statistics on sndbuf/RMB sizes of all connections that have ever been on the link group, namely smc_stats_memsize. However these statistics are incremental and since the ringbufs of link group are allowed to be reused, we cannot know the actual allocated buffers through these. So here introduces the statistic on actual allocated ringbufs of the link group, it will be incremented when a new ringbuf is added into buf_list and decremented when it is deleted from buf_list. Signed-off-by:
-
Zhang Changzhong authored
The check for '!to' is redundant here, since skb_can_coalesce() already contains this check. Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1723730983-22912-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yue Haibing authored
Commit a1ab24e5 ("mptcp: consolidate sockopt synchronization") removed the implementation but leave declaration. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by:
-
Yue Haibing authored
These are never implenmented since commit b691b111 ("net/mlx5: Implement devlink port function cmds to control ipsec_packet"). Signed-off-by:
-
Yue Haibing authored
There is no caller and implementations in tree. Signed-off-by:
-
Yue Haibing authored
Commit f13697cc ("gve: Switch to config-aware queue allocation") convert this function to gve_rx_alloc_rings_gqi(). Signed-off-by:
-
Jakub Kicinski authored
Use the netlink policy to validate IPv6 address length. Destination address currently has policy for max len set, and source has no policy validation. In both cases the code does the real check. With correct policy check the code can be removed. Reviewed-by:
Stephen Hemminger <stephen@networkplumber.org> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20240816212245.467745-1-kuba@kernel.orgSigned-off-by:
-
- 19 Aug, 2024 1 commit
-
-
Frank Li authored
fsl,enetc-ptp is embedded pcie device. Add compatible string pci1957,ee02. Fix warning: arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-kbox-a-230-ls.dtb: ethernet@0,4: compatible:0: 'pci1957,ee02' is not one of ['fsl,etsec-ptp', 'fsl,fman-ptp-timer', 'fsl,dpaa2-ptp', 'fsl,enetc-ptp'] Signed-off-by:
Frank Li <Frank.Li@nxp.com> Acked-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 17 Aug, 2024 2 commits
-
-
Simon Horman authored
In bnx2x_get_vf_config(): * The vlan field of ivi is a 32-bit integer, it is used to store a vlan ID. * The vlan field of bulletin is a 16-bit integer, it is also used to store a vlan ID. In the current code, ivi->vlan is set using memset. But in the case of setting it to the value of bulletin->vlan, this involves reading 32 bits from a 16bit source. This is likely safe, as the following 6 bytes are padding in the same structure, but none the less, it seems undesirable. However, it is entirely unclear to me how this scheme works on big-endian systems. Resolve this by simply assigning integer values to ivi->vlan. Flagged by W=1 builds. f.e. gcc-14 reports: In function 'fortify_memcpy_chk', inlined from 'bnx2x_get_vf_config' at .../bnx2x_sriov.c:2655:4: .../fortify-string.h:580:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 580 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Compile tested only. Signed-off-by:Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20240815-bnx2x-int-vlan-v1-1-5940b76e37ad@kernel.orgSigned-off-by:
-
Christoph Paasch authored
mpls_xmit() needs to prepend the MPLS-labels to the packet. That implies one needs to make sure there is enough space for it in the headers. Calling skb_cow() implies however that one wants to change even the playload part of the packet (which is not true for MPLS). Thus, call skb_cow_head() instead, which is what other tunnelling protocols do. Running a server with this comm it entirely removed the calls to pskb_expand_head() from the callstack in mpls_xmit() thus having significant CPU-reduction, especially at peak times. Cc: Roopa Prabhu <roopa@nvidia.com> Reported-by:
Craig Taylor <cmtaylor@apple.com> Signed-off-by:
Christoph Paasch <cpaasch@apple.com> Reviewed-by:
-
- 16 Aug, 2024 24 commits
-
-
Simon Horman authored
Remove unnecessary NULL check before freeing using kvfree(). This function will ignore a NULL argument. Flagged by Coccinelle: .../txgbe_hw.c:187:2-8: WARNING: NULL check before some freeing functions is not needed. No functional change intended. Compile tested only. Signed-off-by:
-
Aleksander Jan Bajkowski authored
Remove a variable that has never been used. Signed-off-by:
Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20240815074956.155224-1-olek2@wp.plSigned-off-by:
-
Tariq Toukan authored
Following commit 9f7e8fbb ("net/mlx5: offset comp irq index in name by one"), which fixed the index in IRQ name to start once again from 0, we change the documentation accordingly. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Dragos Tatulea <dtatulea@nvidia.com> Link: https://patch.msgid.link/20240815142343.2254247-1-tariqt@nvidia.comSigned-off-by:
-
Frank Li authored
Change mdio.yaml nodename match pattern to '^mdio(-(bus|external))?(@.+|-([0-9]+))$' Fix mdio.yaml wrong parser mdio controller's address instead phy's address when mdio-mux exista. For example: mdio-mux-emi1@54 { compatible = "mdio-mux-mmioreg", "mdio-mux"; mdio@20 { reg = <0x20>; ^^^ This is mdio controller register ethernet-phy@2 { reg = <0x2>; ^^^ This phy's address }; }; }; Only phy's address is limited to 31 because MDIO bus definition. But CHECK_DTBS report below warning: arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dtb: mdio-mux-emi1@54: mdio@20:reg:0:0: 32 is greater than the maximum of 31 The reason is that "mdio-mux-emi1@54" match "nodename: '^mdio(@.*)?'" in mdio.yaml. Change to '^mdio(-(bus|external))?(@.+|-([0-9]+))?$' to avoid wrong match mdio mux controller's node. Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== ice: iavf: add support for TC U32 filters on VFs Ahmed Zaki says: The Intel Ethernet 800 Series is designed with a pipeline that has an on-chip programmable capability called Dynamic Device Personalization (DDP). A DDP package is loaded by the driver during probe time. The DDP package programs functionality in both the parser and switching blocks in the pipeline, allowing dynamic support for new and existing protocols. Once the pipeline is configured, the driver can identify the protocol and apply any HW action in different stages, for example, direct packets to desired hardware queues (flow director), queue groups or drop. Patches 1-8 introduce a DDP package parser API that enables different pipeline stages in the driver to learn the HW parser capabilities from the DDP package that is downloaded to HW. The parser library takes raw packet patterns and masks (in binary) indicating the packet protocol fields to be matched and generates the final HW profiles that can be applied at the required stage. With this API, raw flow filtering for FDIR or RSS could be done on new protocols or headers without any driver or Kernel updates (only need to update the DDP package). These patches were submitted before [1] but were not accepted mainly due to lack of a user. Patches 9-11 extend the virtchnl support to allow the VF to request raw flow director filters. Upon receiving the raw FDIR filter request, the PF driver allocates and runs a parser lib instance and generates the hardware profile definitions required to program the FDIR stage. These were also submitted before [2]. Finally, patches 12 and 13 add TC U32 filter support to the iavf driver. Using the parser API, the ice driver runs the raw patterns sent by the user and then adds a new profile to the FDIR stage associated with the VF's VSI. Refer to examples in patch 13 commit message. [1]: https://lore.kernel.org/netdev/20230904021455.3944605-1-junfeng.guo@intel.com/ [2]: https://lore.kernel.org/intel-wired-lan/20230818064703.154183-1-junfeng.guo@intel.com/ * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: iavf: add support for offloading tc U32 cls filters iavf: refactor add/del FDIR filters ice: enable FDIR filters from raw binary patterns for VFs ice: add method to disable FDIR SWAP option virtchnl: support raw packet in protocol header ice: add API for parser profile initialization ice: add UDP tunnels support to the parser ice: support turning on/off the parser's double vlan mode ice: add parser execution main loop ice: add parser internal helper functions ice: add debugging functions for the parser sections ice: parse and init various DDP parser sections ice: add parser create and destroy skeleton ==================== Link: https://patch.msgid.link/20240813222249.3708070-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Pavan Kumar Linga authored
'req_vec_chunks' is used to store the vector info received from the device control plane. The memory for it is allocated in idpf_send_alloc_vectors_msg and returns an error if the memory allocation fails. 'req_vec_chunks' cannot be NULL in the later code flow. So remove the conditional check to extract the vector ids received from the device control plane. Smatch static checker warning: drivers/net/ethernet/intel/idpf/idpf_lib.c:417 idpf_intr_req() error: we previously assumed 'adapter->req_vec_chunks' could be null (see line 360) Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/intel-wired-lan/a355ae8a-9011-4a85-a4d1-5b2793bb5f7b@stanley.mountain/Reviewed-by:
Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20240814175903.4166390-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Rosen Penev says: ==================== use more devm for ag71xx Some of these were introduced after the driver got introduced. In any case, using more devm allows removal of the remove function and overall simplifies the code. All of these were tested on a TP-LINK Archer C7v2. ==================== Link: https://patch.msgid.link/20240813170516.7301-1-rosenp@gmail.comSigned-off-by:
-
Rosen Penev authored
Allows completely removing the remove function. Nothing is being done manually now. Tested on TP-LINK Archer C7v2. Signed-off-by:
Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20240813170516.7301-4-rosenp@gmail.comSigned-off-by:
-
Rosen Penev authored
Allows removing ag71xx_mdio_remove. Removed ag.mii_bus variable. Local one can be used with devm. Easier to reason about as mii_bus is only used here now. Also shrinks the struct slightly. Signed-off-by:
-
Rosen Penev authored
Allows removal of clk_prepare_enable to simplify the code slightly. Tested on a TP-LINK Archer C7v2. Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== selftests: fib_rule_tests: Cleanups and new tests This patchset performs some cleanups and adds new tests in preparation for upcoming FIB rule DSCP selector. ==================== Link: https://patch.msgid.link/20240814111005.955359-1-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
The TOS value reaches the FIB rule core via different call paths when an input route is looked up compared to an output route. Re-test TOS matching with input routes to exercise these code paths. Pass the 'iif' and 'from' selectors separately from the 'get{,no}match' variables as otherwise the test name is too long to be printed without misalignments. Signed-off-by: -
Ido Schimmel authored
The fib_rule{4,6}_connect tests verify that locally generated traffic from a socket that specifies a DS Field using the IP_TOS / IPV6_TCLASS socket options is correctly redirected using a FIB rule that matches on the given DS Field. Add negative tests to verify that the FIB rule is not hit when the socket specifies a DS Field that differs from the one used by the FIB rule. Signed-off-by: -
Ido Schimmel authored
The fib_rule{4,6} tests verify the behavior of a given FIB rule selector (e.g., dport, sport) by redirecting to a routing table with a default route using a FIB rule with the given selector and checking that a route lookup using the selector matches this default route. Add negative tests to verify that a FIB rule is not hit when it should not. Signed-off-by: -
Ido Schimmel authored
Clarify the test results by grouping the output of test cases belonging to the same test under a common title. This is consistent with the output of fib_tests.sh. Before: # ./fib_rule_tests.sh TEST: rule6 check: oif redirect to table [ OK ] TEST: rule6 del by pref: oif redirect to table [ OK ] [...] TEST: rule4 check: oif redirect to table [ OK ] TEST: rule4 del by pref: oif redirect to table [ OK ] [...] Tests passed: 116 Tests failed: 0 After: # ./fib_rule_tests.sh IPv6 FIB rule tests TEST: rule6 check: oif redirect to table [ OK ] TEST: rule6 del by pref: oif redirect to table [ OK ] [...] IPv4 FIB rule tests TEST: rule4 check: oif redirect to table [ OK ] TEST: rule4 del by pref: oif redirect to table [ OK ] [...] Tests passed: 116 Tests failed: 0 Signed-off-by: -
Ido Schimmel authored
The functions are unused since commit 816cda9a ("selftests: net: fib_rule_tests: add support to select a test to run"). Remove them. Signed-off-by:
-
Jakub Kicinski authored
Simon Horman says: ==================== ipv6: Add ipv6_addr_{cpu_to_be32,be32_to_cpu} helpers This series adds and uses some new helpers, ipv6_addr_{cpu_to_be32,be32_to_cpu}, which are intended to assist in byte order manipulation of IPv6 addresses stored as as arrays. v1: https://lore.kernel.org/r/20240812-ipv6_addr-helpers-v1-0-aab5d1f35c40@kernel.org ==================== Link: https://patch.msgid.link/20240813-ipv6_addr-helpers-v2-0-5c974f8cca3e@kernel.orgSigned-off-by: -
Simon Horman authored
Use new ipv6_addr_cpu_to_be32 and ipv6_addr_be32_to_cpu helpers, and IPV6_ADDR_WORDS. This is arguably slightly nicer. No functional change intended. Compile tested only. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/netdev/c7684349-535c-45a4-9a74-d47479a50020@lunn.ch/Reviewed-by:
Jijie Shao <shaojijie@huawei.com> Signed-off-by:
-
Simon Horman authored
Use ipv6_addr_cpu_to_be32 and ipv6_addr_be32_to_cpu helpers to convert address, rather than open coding the conversion. No functional change intended. Compile tested only. Suggested-by:
-
Simon Horman authored
Add helpers to convert an ipv6 addr, expressed as an array of words, from CPU to big-endian byte order, and vice versa. No functional change intended. Compile tested only. Suggested-by:
-
Jakub Kicinski authored
Pieter Van Trappen says: ==================== net: dsa: microchip: ksz8795: add Wake on LAN support Add WoL support for KSZ8795 family of switches. This code was tested with a KSZ8794 chip. Strongly based on existing KSZ9477 code which has now been moved to ksz_common instead of duplicating, as proposed during the review of the v1 version of this patch. In addition to the device-tree addition and the actual code, there's two additional patches that fix some bugs found when further testing DSA with this KSZ8794 chip. v5: https://lore.kernel.org/20240812153015.653044-1-vtpieter@gmail.com v4: https://lore.kernel.org/20240812084945.578993-1-vtpieter@gmail.com v3: https://lore.kernel.org/20240806132606.1438953-1-vtpieter@gmail.com v2: https://lore.kernel.org/20240731103403.407818-1-vtpieter@gmail.com v1: https://lore.kernel.org/20240717193725.469192-1-vtpieter@gmail.com ==================== Link: https://patch.msgid.link/20240813142750.772781-1-vtpieter@gmail.comSigned-off-by:
-
Pieter Van Trappen authored
Fix the tag_ksz egress mask for DSA_TAG_PROTO_KSZ8795, the port is encoded in the two and not three LSB. This fix is for completeness, for example the bug doesn't manifest itself on the KSZ8794 because bit 2 seems to be always zero. Signed-off-by:
Pieter Van Trappen <pieter.van.trappen@cern.ch> Acked-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://patch.msgid.link/20240813142750.772781-7-vtpieter@gmail.comSigned-off-by:
-
Pieter Van Trappen authored
The KSZ87xx switches have 32 static MAC address table entries and not 8. This fixes -ENOSPC non-critical errors from ksz8_add_sta_mac when configured as a bridge. Add a new ksz87xx_dev_ops structure to be able to use the ksz_r_mib_stat64 pointer for this family; this corrects a wrong mib->counters cast to ksz88xx_stats_raw. This fixes iproute2 statistics. Rename ksz8_dev_ops structure to ksz88x3_dev_ops, in line with ksz_is_* naming conventions from ksz_common.h. Signed-off-by:
-
Pieter Van Trappen authored
Add WoL support for KSZ87xx family of switches. This code was tested with a KSZ8794 chip. Implement ksz_common usage of the new device-tree property 'microchip,pme-active-high'. Make use of the now generalized ksz_common WoL functions, adding an additional interrupt register write for KSZ87xx. Add helper functions to convert from PME (port) read/writes to indirect register read/writes in the dedicated ksz8795 sources. Add initial configuration during (port) setup as per KSZ9477. Signed-off-by:
-
