- 15 Jul, 2024 4 commits
-
-
Kory Maincent authored
In prevision to add new UAPI for hwtstamp we will be limited to the struct ethtool_ts_info that is currently passed in fixed binary format through the ETHTOOL_GET_TS_INFO ethtool ioctl. It would be good if new kernel code already started operating on an extensible kernel variant of that structure, similar in concept to struct kernel_hwtstamp_config vs struct hwtstamp_config. Since struct ethtool_ts_info is in include/uapi/linux/ethtool.h, here we introduce the kernel-only structure in include/linux/ethtool.h. The manual copy is then made in the function called by ETHTOOL_GET_TS_INFO. Acked-by:
Shannon Nelson <shannon.nelson@amd.com> Acked-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240709-feature_ptp_netnext-v17-6-b5317f50df2a@bootlin.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kory Maincent authored
Prepare for future support of saving hwtstamp source in PTP xarray by introducing HWTSTAMP_SOURCE_UNSPEC to hwtstamp_source enum, setting it to 0 to match old behavior of no source defined. Signed-off-by:
-
Kory Maincent authored
Change the API to select MAC default time stamping instead of the PHY. Indeed the PHY is closer to the wire therefore theoretically it has less delay than the MAC timestamping but the reality is different. Due to lower time stamping clock frequency, latency in the MDIO bus and no PHC hardware synchronization between different PHY, the PHY PTP is often less precise than the MAC. The exception is for PHY designed specially for PTP case but these devices are not very widespread. For not breaking the compatibility default_timestamp flag has been introduced in phy_device that is set by the phy driver to know we are using the old API behavior. Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by:
-
Kory Maincent authored
Timestamping software or hardware flags are often used as a group, therefore adding these masks will ease future use. I did not use SOF_TIMESTAMPING_SYS_HARDWARE flag as it is deprecated and not used at all. Reviewed-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
- 09 Jul, 2024 4 commits
-
-
Jakub Kicinski authored
Bartosz Golaszewski says: ==================== net: stmmac: qcom-ethqos: enable 2.5G ethernet on sa8775p-ride Here are the changes required to enable 2.5G ethernet on sa8775p-ride. As advised by Andrew Lunn and Russell King, I am reusing the existing stmmac infrastructure to enable the SGMII loopback and so I dropped the patches adding new callbacks to the driver core. I also added more details to the commit message and made sure the workaround is only enabled on Rev 3 of the board (with AQR115C PHY). Also: dropped any mentions of the OCSGMII mode. v2: https://lore.kernel.org/20240627113948.25358-1-brgl@bgdev.pl v1: https://lore.kernel.org/20240619184550.34524-1-brgl@bgdev.pl ==================== Link: https://patch.msgid.link/20240703181500.28491-1-brgl@bgdev.plSigned-off-by:
-
Bartosz Golaszewski authored
On sa8775p-ride-r3 the RX clocks from the AQR115C PHY are not available at the time of the DMA reset. We can however extract the RX clock from the internal SERDES block. Once the link is up, we can revert to the previous state. The AQR115C PHY doesn't support in-band signalling so we can count on getting the link up notification and safely reuse existing callbacks which are already used by another HW quirk workaround which enables the functional clock to avoid a DMA reset due to timeout. Only enable loopback on revision 3 of the board - check the phy_mode to make sure. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240703181500.28491-3-brgl@bgdev.plSigned-off-by:
-
Bartosz Golaszewski authored
Add support for 2.5G speed in 2500BASEX mode to the QCom ethqos driver. Signed-off-by:
-
Johannes Berg authored
WARN_ON_ONCE("string") doesn't really do what appears to be intended, so fix that. Signed-off-by:Johannes Berg <johannes.berg@intel.com> Fixes: 90de47f0 ("page_pool: fragment API support for 32-bit arch with 64-bit DMA") Link: https://patch.msgid.link/20240705134221.2f4de205caa1.I28496dc0f2ced580282d1fb892048017c4491e21@changeidSigned-off-by:
-
- 08 Jul, 2024 3 commits
-
-
Jakub Kicinski authored
It's very useful to be able to interrupt the tests during development. Detect KeyboardInterrupt, run the cleanups and exit. Link: https://patch.msgid.link/20240705015222.675840-1-kuba@kernel.orgSigned-off-by:
-
Oleksij Rempel authored
Set proper MAC capabilities for port 4 on LAN9371 and LAN9372 switches with integrated 100BaseTX PHY. And introduce the is_lan937x_tx_phy() function to reuse it where applicable. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
At this time, conntrack either returns NF_ACCEPT or NF_DROP. To improve debuging it would be nice to be able to replace NF_DROP verdict with NF_DROP_REASON() helper, This helper releases the skb instantly (so drop_monitor can pinpoint exact location) and returns NF_STOLEN. Prepare call sites to deal with this before introducing such changes in conntrack and nat core. Signed-off-by:
Florian Westphal <fw@strlen.de> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
- 06 Jul, 2024 26 commits
-
-
Jakub Kicinski authored
Kory Maincent says: ==================== net: pse-pd: Add new PSE c33 features This patch series adds new c33 features to the PSE API. - Expand the PSE PI informations status with power, class and failure reason - Add the possibility to get and set the PSE PIs power limit v5: https://lore.kernel.org/r/20240628-feature_poe_power_cap-v5-0-5e1375d3817a@bootlin.com v4: https://lore.kernel.org/r/20240625-feature_poe_power_cap-v4-0-b0813aad57d5@bootlin.com v3: https://lore.kernel.org/r/20240614-feature_poe_power_cap-v3-0-a26784e78311@bootlin.com v2: https://lore.kernel.org/r/20240607-feature_poe_power_cap-v2-0-c03c2deb83ab@bootlin.com v1: https://lore.kernel.org/r/20240529-feature_poe_power_cap-v1-0-0c4b1d5953b8@bootlin.com ==================== Link: https://patch.msgid.link/20240704-feature_poe_power_cap-v6-0-320003204264@bootlin.comSigned-off-by:
-
Kory Maincent (Dent Project) authored
This patch expands PSE callbacks with newly introduced pi_get/set_current_limit() and pi_get_voltage() callback. It also add the power limit ranges description in the status returned. The only way to set ps692x0 port power limit is by configure the power class plus a small power supplement which maximum depends on each class. Acked-by:
-
Kory Maincent (Dent Project) authored
Expand the c33 PSE attributes with power limit to be able to set and get the PSE Power Interface power limit. ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-get --json '{"header":{"dev-name":"eth1"}}' {'c33-pse-actual-pw': 1700, 'c33-pse-admin-state': 3, 'c33-pse-avail-pw-limit': 97500, 'c33-pse-pw-class': 4, 'c33-pse-pw-d-status': 4, 'c33-pse-pw-limit-ranges': [{'max': 18100, 'min': 15000}, {'max': 38000, 'min': 30000}, {'max': 65000, 'min': 60000}, {'max': 97500, 'min': 90000}], 'header': {'dev-index': 5, 'dev-name': 'eth1'}} ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-set --json '{"header":{"dev-name":"eth1"}, "c33-pse-avail-pw-limit":19000}' None Signed-off-by: -
Kory Maincent (Dent Project) authored
This patch expands the status information provided by ethtool for PSE c33 with available power limit and available power limit ranges. It also adds a call to pse_ethtool_set_pw_limit() to configure the PSE control power limit. Reviewed-by:
-
Kory Maincent (Dent Project) authored
This patch add a way to get and set the power limit of a PSE PI. For that it uses regulator API callbacks wrapper like get_voltage() and get/set_current_limit() as power is simply V * I. We used mW unit as defined by the IEEE 802.3-2022 standards. set_current_limit() uses the voltage return by get_voltage() and the desired power limit to calculate the current limit. get_voltage() callback is then mandatory to set the power limit. get_current_limit() callback is by default looking at a driver callback and fallback to extracting the current limit from _pse_ethtool_get_status() if the driver does not set its callback. We prefer let the user the choice because ethtool_get_status return much more information than the current limit. expand pse status with c33_pw_limit_ranges to return the ranges available to configure the power limit. Reviewed-by:
Sai Krishna <saikrishnag@marvell.com> Acked-by:
-
Kory Maincent (Dent Project) authored
This update expands pd692x0_ethtool_get_status() callback with newly introduced details such as the detected class, current power delivered, and extended state information. Acked-by:
-
Kory Maincent (Dent Project) authored
Expand the c33 PSE attributes with PSE class, extended state information and power consumption. ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-get --json '{"header":{"dev-name":"eth0"}}' {'c33-pse-actual-pw': 1700, 'c33-pse-admin-state': 3, 'c33-pse-pw-class': 4, 'c33-pse-pw-d-status': 4, 'header': {'dev-index': 4, 'dev-name': 'eth0'}} ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do pse-get --json '{"header":{"dev-name":"eth0"}}' {'c33-pse-admin-state': 3, 'c33-pse-ext-state': 'mr-mps-valid', 'c33-pse-ext-substate': 2, 'c33-pse-pw-d-status': 2, 'header': {'dev-index': 4, 'dev-name': 'eth0'}} Signed-off-by: -
Kory Maincent (Dent Project) authored
This update expands the status information provided by ethtool for PSE c33. It includes details such as the detected class, current power delivered, and extended state information. Reviewed-by:
-
Jakub Kicinski authored
Adrian Moreno says: ==================== net: openvswitch: Add sample multicasting. ** Background ** Currently, OVS supports several packet sampling mechanisms (sFlow, per-bridge IPFIX, per-flow IPFIX). These end up being translated into a userspace action that needs to be handled by ovs-vswitchd's handler threads only to be forwarded to some third party application that will somehow process the sample and provide observability on the datapath. A particularly interesting use-case is controller-driven per-flow IPFIX sampling where the OpenFlow controller can add metadata to samples (via two 32bit integers) and this metadata is then available to the sample-collecting system for correlation. ** Problem ** The fact that sampled traffic share netlink sockets and handler thread time with upcalls, apart from being a performance bottleneck in the sample extraction itself, can severely compromise the datapath, yielding this solution unfit for highly loaded production systems. Users are left with little options other than guessing what sampling rate will be OK for their traffic pattern and system load and dealing with the lost accuracy. Looking at available infrastructure, an obvious candidated would be to use psample. However, it's current state does not help with the use-case at stake because sampled packets do not contain user-defined metadata. ** Proposal ** This series is an attempt to fix this situation by extending the existing psample infrastructure to carry a variable length user-defined cookie. The main existing user of psample is tc's act_sample. It is also extended to forward the action's cookie to psample. Finally, a new OVS action (OVS_SAMPLE_ATTR_PSAMPLE) is created. It accepts a group and an optional cookie and uses psample to multicast the packet and the metadata. ==================== Link: https://patch.msgid.link/20240704085710.353845-1-amorenoz@redhat.comSigned-off-by:
-
Adrian Moreno authored
Add a test to verify sampling packets via psample works. In order to do that, create a subcommand in ovs-dpctl.py to listen to on the psample multicast group and print samples. Reviewed-by:
Aaron Conole <aconole@redhat.com> Tested-by:
Ilya Maximets <i.maximets@ovn.org> Signed-off-by:
Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-11-amorenoz@redhat.comSigned-off-by:
-
Adrian Moreno authored
The trunc action was supported decode-able but not parse-able. Add support for parsing the action string. Reviewed-by:
-
Adrian Moreno authored
The userspace action lacks parsing support plus it contains a bug in the name of one of its attributes. This patch makes userspace action work. Reviewed-by:
-
Adrian Moreno authored
Add sample and psample action support to ovs-dpctl.py. Refactor common attribute parsing logic into an external function. Reviewed-by:
-
Adrian Moreno authored
When a packet sample is observed, the sampling rate that was used is important to estimate the real frequency of such event. Store the probability of the parent sample action in the skb's cb area and use it in psample action to pass it down to psample module. Reviewed-by:
Eelco Chaudron <echaudro@redhat.com> Reviewed-by:
-
Adrian Moreno authored
Add support for a new action: psample. This action accepts a u32 group id and a variable-length cookie and uses the psample multicast group to make the packet available for observability. The maximum length of the user-defined cookie is set to 16, same as tc_cookie, to discourage using cookies that will not be offloadable. Reviewed-by:
Michal Kubiak <michal.kubiak@intel.com> Reviewed-by:
-
Adrian Moreno authored
Although not explicitly documented in the psample module itself, the definition of PSAMPLE_ATTR_SAMPLE_RATE seems inherited from act_sample. Quoting tc-sample(8): "RATE of 100 will lead to an average of one sampled packet out of every 100 observed." With this semantics, the rates that we can express with an unsigned 32-bits number are very unevenly distributed and concentrated towards "sampling few packets". For example, we can express a probability of 2.32E-8% but we cannot express anything between 100% and 50%. For sampling applications that are capable of sampling a decent amount of packets, this sampling rate semantics is not very useful. Add a new flag to the uAPI that indicates that the sampling rate is expressed in scaled probability, this is: - 0 is 0% probability, no packets get sampled. - U32_MAX is 100% probability, all packets get sampled. Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Adrian Moreno authored
If nobody is listening on the multicast group, generating the sample, which involves copying packet data, seems completely unnecessary. Return fast in this case. Reviewed-by:
-
Adrian Moreno authored
If the action has a user_cookie, pass it along to the sample so it can be easily identified. Reviewed-by:
-
Adrian Moreno authored
Add a user cookie to the sample metadata so that sample emitters can provide more contextual information to samples. If present, send the user cookie in a new attribute: PSAMPLE_ATTR_USER_COOKIE. Reviewed-by:
-
Daniel Golle authored
Implement operations to get and set flow-control link parameters. Both is done by simply calling phylink_ethtool_{get,set}_pauseparam(). Fix whitespace in mtk_ethtool_ops while at it. Signed-off-by:Daniel Golle <daniel@makrotopia.org> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by:
Rui Salvaterra <rsalvaterra@gmail.com> Link: https://patch.msgid.link/e3ece47323444631d6cb479f32af0dfd6d145be0.1720088047.git.daniel@makrotopia.orgSigned-off-by:
-
Shengyu Qu authored
MT7981,7986 and 7988 all supports 32768 PPE entries, and MT7621/MT7620 supports 16384 PPE entries, but only set to 8192 entries in driver. So incrase max entries to 16384 instead. Signed-off-by:
Elad Yifee <eladwf@gmail.com> Signed-off-by:
Shengyu Qu <wiagn233@outlook.com> Reviewed-by:
-
Jakub Kicinski authored
Javier Carrasco says: ==================== net: constify struct regmap_bus/regmap_config This series adds the const modifier to the remaining regmap_bus and regmap_config structs within the net subsystem that are effectively used as const (i.e., only read after their declaration), but kept as writtable data. ==================== Link: https://patch.msgid.link/20240703-net-const-regmap-v1-0-ff4aeceda02c@gmail.comSigned-off-by:
-
Javier Carrasco authored
`ar9331_sw_bus` is not modified and can be declared as const to move its data to a read-only section. Signed-off-by:
Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240703-net-const-regmap-v1-4-ff4aeceda02c@gmail.comSigned-off-by:
-
Javier Carrasco authored
`regmap_encx24j600`, `phycfg` and `phymap_encx24j600` are not modified and can be declared as const to move their data to a read-only section. Signed-off-by:
-
Javier Carrasco authored
`am654_icss_iep_regmap_config` is only assigned to a pointer that passes the data as read-only. Add the const modifier to the struct and pointer to move the data to a read-only section. Signed-off-by:
Roger Quadros <rogerq@kernel.org> Reviewed-by:
MD Danish Anwar <danishanwar@ti.com> Link: https://patch.msgid.link/20240703-net-const-regmap-v1-2-ff4aeceda02c@gmail.comSigned-off-by:
-
Javier Carrasco authored
`qca8k_regmap_config` is not modified and can be declared as const to move its data to a read-only section. Signed-off-by:
-
- 05 Jul, 2024 3 commits
-
-
Sebastian Andrzej Siewior authored
During the introduction of struct bpf_net_context handling for XDP-redirect, the tun driver has been missed. Jakub also pointed out that there is another call chain to do_xdp_generic() originating from netif_receive_skb() and drivers may use it outside from the NAPI context. Set the bpf_net_context before invoking BPF XDP program within the TUN driver. Set the bpf_net_context also in do_xdp_generic() if a xdp program is available. Reported-by: syzbot+0b5c75599f1d872bea6f@syzkaller.appspotmail.com Reported-by: syzbot+5ae46b237278e2369cac@syzkaller.appspotmail.com Reported-by: syzbot+c1e04a422bbc0f0f2921@syzkaller.appspotmail.com Fixes: 401cb7da ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20240704144815.j8xQda5r@linutronix.deSigned-off-by:
-
Daniel Golle authored
Some devices with MediaTek SoCs don't use the first but only the second MAC in the chip. Especially with MT7981 which got a built-in 1GE PHY connected to the second MAC this is quite common. Make sure to reset and enable PSE also in those cases by skipping gaps using 'continue' instead of aborting the loop using 'break'. Fixes: dee4dd10 ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs") Suggested-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/379ae584cea112db60f4ada79c7e5ba4f3364a64.1719862038.git.daniel@makrotopia.orgSigned-off-by:
-
Florian Westphal authored
At this time, conntrack either returns NF_ACCEPT or NF_DROP. To improve debuging it would be nice to be able to replace NF_DROP verdict with NF_DROP_REASON() helper, This helper releases the skb instantly (so drop_monitor can pinpoint precise location) and returns NF_STOLEN. Prepare call sites to deal with this before introducing such changes in conntrack and nat core. Signed-off-by:
Aaron Conole <aconole@redhat.om> Signed-off-by:
-
