- 06 Jul, 2024 19 commits
-
-
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: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240704-feature_poe_power_cap-v6-1-320003204264@bootlin.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
Adrian Moreno authored
The trunc action was supported decode-able but not parse-able. Add support for parsing the action string. Reviewed-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-10-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Aaron Conole <aconole@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-9-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Adrian Moreno authored
Add sample and psample action support to ovs-dpctl.py. Refactor common attribute parsing logic into an external function. Reviewed-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-8-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-7-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Aaron Conole <aconole@redhat.com> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-6-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-5-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-4-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Adrian Moreno authored
If the action has a user_cookie, pass it along to the sample so it can be easily identified. Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-3-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Michal Kubiak <michal.kubiak@intel.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Link: https://patch.msgid.link/20240704085710.353845-2-amorenoz@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Michal Kubiak <michal.kubiak@intel.com> 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: Jakub Kicinski <kuba@kernel.org>
-
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: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/TY3P286MB261103F937DE4EEB0F88437D98DE2@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COMSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
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 <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20240703-net-const-regmap-v1-3-ff4aeceda02c@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-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: Jakub Kicinski <kuba@kernel.org>
-
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: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240703-net-const-regmap-v1-1-ff4aeceda02c@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 05 Jul, 2024 15 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: Jakub Kicinski <kuba@kernel.org>
-
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: Elad Yifee <eladwf@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/379ae584cea112db60f4ada79c7e5ba4f3364a64.1719862038.git.daniel@makrotopia.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Florian Westphal <fw@strlen.de> Reviewed-by: Aaron Conole <aconole@redhat.om> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Serge Semin <fancer says: ==================== net: pcs: xpcs: Add memory-mapped device support The main goal of this series is to extend the DW XPCS device support in the kernel. Particularly the patchset adds a support of the DW XPCS device with the MCI/APB3 IO interface registered as a platform device. In order to have them utilized by the DW XPCS core the fwnode-based DW XPCS descriptor creation procedure has been introduced. Finally the STMMAC driver has been altered to support the DW XPCS passed via the 'pcs-handle' property. Note the series has been significantly re-developed since v1. So I even had to change the subject. Anyway I've done my best to take all the noted into account. The series traditionally starts with a set of the preparation patches. First one just moves the generic DW XPCS IDs macros from the internal header file to the external one where some other IDs also reside. Second patch splits up the xpcs_create() method to a set of the coherent sub-functions for the sake of the further easier updates and to have it looking less complicated. The goal of the next three patches is to extend the DW XPCS ID management code by defining a new dw_xpcs_info structure with both PCS and PMA IDs. The next two patches provide the DW XPCS device DT-bindings and the respective platform-device driver for the memory-mapped DW XPCS devices. Besides the later patch makes use of the introduced dw_xpcs_info structure to pre-define the DW XPCS IDs based on the platform-device compatible string. Thus if there is no way to auto-identify the XPCS device capabilities it can be done based on the custom device IDs passed via the MDIO-device platform data. Final DW XPCS driver change is about adding a new method of the DW XPCS descriptor creation. The xpcs_create_fwnode() function has been introduced with the same semantics as a similar method recently added to the Lynx PCS driver. It's supposed to be called with the fwnode pointing to the DW XPCS device node, for which the XPCS descriptor will be created. The series is terminated with two STMMAC driver patches. The former one simplifies the DW XPCS descriptor registration procedure by dropping the MDIO-bus scanning and creating the descriptor for the particular device address. The later patch alters the STMMAC PCS setup method so one would support the DW XPCS specified via the "pcs-handle" property. That's it for now. Thanks for review in advance. Any tests are very welcome. After this series is merged in, I'll submit another one which adds the generic 10GBase-R and 10GBase-X interfaces support to the STMMAC and DW XPCS driver with the proper CSRs re-initialization, PMA initialization and reference clock selection as it's described in the Synopsys DW XPCS HW manual. Link: https://lore.kernel.org/netdev/20231205103559.9605-1-fancer.lancer@gmail.com Changelog v2: - Drop the patches: [PATCH net-next 01/16] net: pcs: xpcs: Drop sentinel entry from 2500basex ifaces list [PATCH net-next 02/16] net: pcs: xpcs: Drop redundant workqueue.h include directive [PATCH net-next 03/16] net: pcs: xpcs: Return EINVAL in the internal methods [PATCH net-next 04/16] net: pcs: xpcs: Explicitly return error on caps validation as ones have already been merged into the kernel repo: Link: https://lore.kernel.org/netdev/20240222175843.26919-1-fancer.lancer@gmail.com/ - Drop the patches: [PATCH net-next 14/16] net: stmmac: Pass netdev to XPCS setup function [PATCH net-next 15/16] net: stmmac: Add dedicated XPCS cleanup method as ones have already been merged into the kernel repo: Link: https://lore.kernel.org/netdev/20240513-rzn1-gmac1-v7-0-6acf58b5440d@bootlin.com/ - Drop the patch: [PATCH net-next 06/16] net: pcs: xpcs: Avoid creating dummy XPCS MDIO device [PATCH net-next 09/16] net: mdio: Add Synopsys DW XPCS management interface support [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr" [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO device as no longer relevant. - Add new patches: [PATCH net-next v2 03/10] net: pcs: xpcs: Convert xpcs_id to dw_xpcs_desc [PATCH net-next v2 04/10] net: pcs: xpcs: Convert xpcs_compat to dw_xpcs_compat [PATCH net-next v2 05/10] net: pcs: xpcs: Introduce DW XPCS info structure [PATCH net-next v2 09/10] net: stmmac: Create DW XPCS device with particular address - Use the xpcs_create_fwnode() function name and semantics similar to the Lynx PCS driver. - Add kdoc describing the DW XPCS registration functions. - Convert the memory-mapped DW XPCS device driver to being the platform-device driver. - Convert the DW XPCS DT-bindings to defining both memory-mapped and MDIO devices. - Drop inline'es from the methods statically defined in *.c. (@Maxime) - Preserve the strict refcount-ing pattern. (@Russell) Link: https://lore.kernel.org/netdev/20240602143636.5839-1-fancer.lancer@gmail.com/ Changelov v3: - Implement the ordered clocks constraint. (@Rob) - Convert xpcs_plat_pm_ops to being defined as static. (@Simon) - Add the "@interface" argument kdoc to the xpcs_create_mdiodev() function. (@Simon) - Fix the "@fwnode" argument name in the xpcs_create_fwnode() method kdoc. (@Simon) - Move the return value descriptions to the "Return:" section of the xpcs_create_mdiodev() and xpcs_create_fwnode() kdoc. (@Simon) - Drop stmmac_mdio_bus_data::has_xpcs flag and define the PCS-address mask with particular XPCS address instead. Link: https://lore.kernel.org/netdev/20240627004142.8106-1-fancer.lancer@gmail.com/ Changelog v4: - Make sure the series is applicable to the net-next tree. (@Vladimir) - Rename entry to desc in the xpcs_init_id() method. (@Andrew) - Add a comment to the clock-names property constraint about the oneOf-subschemas applicability. (@Conor) - Convert "pclk" clock name to "csr" to match the DW XPCS IP-core input signal name. (@Rob) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
Recently the DW XPCS DT-bindings have been introduced and the DW XPCS driver has been altered to support the DW XPCS registered as a platform device. In order to have the DW XPCS DT-device accessed from the STMMAC driver let's alter the STMMAC PCS-setup procedure to support the "pcs-handle" property containing the phandle reference to the DW XPCS device DT-node. The respective fwnode will be then passed to the xpcs_create_fwnode() function which in its turn will create the DW XPCS descriptor utilized in the main driver for the PCS-related setups. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
Currently the only STMMAC platform driver using the DW XPCS code is the Intel mGBE device driver. (It can be determined by finding all the drivers having the stmmac_mdio_bus_data::has_xpcs flag set.) At the same time the low-level platform driver masks out the DW XPCS MDIO-address from being auto-detected as PHY by the MDIO subsystem core. Seeing the PCS MDIO ID is known the procedure of the DW XPCS device creation can be simplified by dropping the loop over all the MDIO IDs. From now the DW XPCS device descriptor will be created for the MDIO-bus address pre-defined by the platform drivers via the stmmac_mdio_bus_data::pcs_mask field. Note besides this shall speed up a bit the Intel mGBE probing. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
It's now possible to have the DW XPCS device defined as a standard platform device for instance in the platform DT-file. Although that functionality is useless unless there is a way to have the device found by the client drivers (STMMAC/DW *MAC, NXP SJA1105 Eth Switch, etc). Provide such ability by means of the xpcs_create_fwnode() method. It needs to be called with the device DW XPCS fwnode instance passed. That node will be then used to find the MDIO-device instance in order to create the DW XPCS descriptor. Note the method semantics and name is similar to what has been recently introduced in the Lynx PCS driver. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
Synopsys DesignWare XPCS IP-core can be synthesized with the device CSRs being accessible over the MCI or APB3 interface instead of the MDIO bus (see the CSR_INTERFACE HDL parameter). Thus all the PCS registers can be just memory mapped and be a subject of the standard MMIO operations of course taking into account the peculiarities of the Clause C45 CSRs mapping. From that perspective the DW XPCS devices would look as just normal platform devices for the kernel. On the other hand in order to have the DW XPCS devices handled by the pcs-xpcs.c driver they need to be registered in the framework of the MDIO-subsystem. So the suggested change is about providing a DW XPCS platform device driver registering a virtual MDIO-bus with a single MDIO-device representing the DW XPCS device. DW XPCS platform device is supposed to be described by the respective compatible string "snps,dw-xpcs" (or with the PMA-specific compatible string), CSRs memory space and optional peripheral bus and reference clock sources. Depending on the INDIRECT_ACCESS IP-core synthesize parameter the memory-mapped reg-space can be represented as either directly or indirectly mapped Clause 45 space. In the former case the particular address is determined based on the MMD device and the registers offset (5 + 16 bits all together) within the device reg-space. In the later case there is only 8 lower address bits are utilized for the registers mapping (255 CSRs). The upper bits are supposed to be written into the respective viewport CSR in order to select the respective MMD sub-page. Note, only the peripheral bus clock source is requested in the platform device probe procedure. The core and pad clocks handling has been implemented in the framework of the xpcs_create() method intentionally since the clocks-related setups are supposed to be performed later, during the DW XPCS main configuration procedures. (For instance they will be required for the DW Gen5 10G PMA configuration.) Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
Synopsys DesignWare XPCS IP-core is a Physical Coding Sublayer (PCS) layer providing an interface between the Media Access Control (MAC) and Physical Medium Attachment Sublayer (PMA) through a Media independent interface. From software point of view it exposes IEEE std. Clause 45 CSR space and can be accessible either by MDIO or MCI/APB3 bus interfaces. In the former case the PCS device is supposed to be defined under the respective MDIO bus DT-node. In the later case the DW xPCS will be just a normal IO memory-mapped device. Besides of that DW XPCS DT-nodes can have an interrupt signal and clock source properties specified. The former one indicates the Clause 73/37 auto-negotiation events like: negotiation page received, AN is completed or incompatible link partner. The clock DT-properties can describe up to three clock sources: peripheral bus clock source, internal reference clock and the externally connected reference clock. Finally the DW XPCS IP-core can be optionally synthesized with a vendor-specific interface connected to the Synopsys PMA (also called DesignWare Consumer/Enterprise PHY). Alas that isn't auto-detectable in a portable way. So if the DW XPCS device has the respective PMA attached then it should be reflected in the DT-node compatible string so the driver would be aware of the PMA-specific device capabilities (mainly connected with CSRs available for the fine-tunings). Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
The being introduced structure will preserve the PCS and PMA IDs retrieved from the respective DW XPCS MMDs or potentially pre-defined by the client drivers. (The later change will be introduced later in the framework of the commit adding the memory-mapped DW XPCS devices support.) The structure fields are filled in in the xpcs_get_id() function, which used to be responsible for the PCS Device ID getting only. Besides of the PCS ID the method now fetches the PMA/PMD IDs too from MMD 1, which used to be done in xpcs_dev_flag(). The retrieved PMA ID will be from now utilized for the PMA-specific tweaks like it was introduced for the Wangxun TxGBE PCS in the commit f629acc6 ("net: pcs: xpcs: support to switch mode for Wangxun NICs"). Note 1. The xpcs_get_id() error-handling semantics has been changed. From now the error number will be returned from the function. There is no point in the next IOs or saving 0xffs and then looping over the actual device IDs if device couldn't be reached. -ENODEV will be returned if the very first IO operation failed thus indicating that no device could be found. Note 2. The PCS and PMA IDs macros have been converted to enum'es. The enum'es will be populated later in another commit with the virtual IDs identifying the DW XPCS devices which have some platform-specifics, but have been synthesized with the default PCS/PMA ID. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
The xpcs_compat structure has been left as the only dw-prefix-less structure since the previous commit. Let's unify at least the structures naming in the driver by adding the dw_-prefix to it. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
A structure with the PCS/PMA MMD IDs data is being introduced in one of the next commits. In order to prevent the names ambiguity let's convert the xpcs_id structure name to dw_xpcs_desc. The later version is more suitable since the structure content is indeed the device descriptor containing the data and callbacks required for the driver to correctly set the device up. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
As an initial preparation before adding the fwnode-based DW XPCS device support let's split the xpcs_create() function code up to a set of the small sub-functions. Thus the xpcs_create() implementation will get to look simpler and turn to be more coherent. Further updates will just touch the new sub-functions a bit: add platform-specific device info, add the reference clock getting and enabling. The xpcs_create() method will now contain the next static methods calls: xpcs_create_data() - create the DW XPCS device descriptor, pre-initialize it' fields and increase the mdio device refcount-er; xpcs_init_id() - find XPCS ID instance and save it in the device descriptor; xpcs_init_iface() - find MAC/PCS interface descriptor and perform basic initialization specific to it: soft-reset, disable polling. The update doesn't imply any semantic change but merely makes the code looking simpler and more ready for adding new features support. Note the xpcs_destroy() has been moved to being defined below the xpcs_create_mdiodev() function as the driver now implies having the protagonist-then-antagonist functions definition order. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Serge Semin authored
One of the next commits will alter the DW XPCS driver to support setting a custom device ID for the particular MDIO-device detected on the platform. The generic DW XPCS ID can be used as a custom ID as well in case if the DW XPCS-device was erroneously synthesized with no or some undefined ID. In addition to that having all supported DW XPCS device IDs defined in a single place will improve the code maintainability and readability. Note while at it rename the macros to being shorter and looking alike to the already defined NXP XPCS ID macro. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rob Herring (Arm) authored
Convention is DT schemas should define all properties at the top-level and not inside of if/then schemas. That minimizes the if/then schemas and is more future proof. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://patch.msgid.link/20240703195827.1670594-2-robh@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 04 Jul, 2024 6 commits
-
-
Edward Cree authored
Commit 31e0aa99 ("ethtool: Veto some operations during firmware flashing process") added a flag module_fw_flash_in_progress to struct net_device. As this is ethtool related state, move it to the recently created struct ethtool_netdev_state, accessed via the 'ethtool' member of struct net_device. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20240703121849.652893-1-edward.cree@amd.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/phy/aquantia/aquantia.h 21934375 ("net: phy: aquantia: add missing include guards") 61578f67 ("net: phy: aquantia: add support for PHY LEDs") drivers/net/ethernet/wangxun/libwx/wx_hw.c bd07a981 ("net: txgbe: remove separate irq request for MSI and INTx") b501d261 ("net: txgbe: add FDIR ATR support") https://lore.kernel.org/all/20240703112936.483c1975@canb.auug.org.au/ include/linux/mlx5/mlx5_ifc.h 048a4036 ("net/mlx5: IFC updates for changing max EQs") 99be5617 ("net/mlx5e: SHAMPO, Re-enable HW-GRO") https://lore.kernel.org/all/20240701133951.6926b2e3@canb.auug.org.au/ Adjacent changes: drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 4130c67c ("wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereference") 3f312651 ("wifi: iwlwifi: mvm: add mvm-specific guard") include/net/mac80211.h 816c6bec ("wifi: mac80211: fix BSS_CHANGED_UNSOL_BCAST_PROBE_RESP") 5a009b42 ("wifi: mac80211: track changes in AP's TPE") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Breno Leitao says: ==================== crypto: caam: Unembed net_dev This will un-embed the net_device struct from inside other struct, so we can add flexible array into net_device. This also enable COMPILE test for FSL_CAAM, as any config option that depends on ARCH_LAYERSCAPE. ==================== Link: https://patch.msgid.link/20240702185557.3699991-1-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Breno Leitao authored
Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_devices from struct dpaa2_caam_priv_per_cpu by converting them into pointers, and allocating them dynamically. Use the leverage alloc_netdev_dummy() to allocate the net_device object at dpaa2_dpseci_setup(). The free of the device occurs at dpaa2_dpseci_disable(). Link: https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-5-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Breno Leitao authored
Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_devices from struct caam_qi_pcpu_priv by converting them into pointers, and allocating them dynamically. Use the leverage alloc_netdev_dummy() to allocate the net_device object at caam_qi_init(). The free of the device occurs at caam_qi_shutdown(). Link: https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-4-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Breno Leitao authored
As most of the drivers that depend on ARCH_LAYERSCAPE, make CRYPTO_DEV_FSL_CAAM depend on COMPILE_TEST for compilation and testing. # grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l 29 Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240702185557.3699991-3-leitao@debian.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-