- 04 Apr, 2023 3 commits
-
-
Íñigo Huguet authored
When sending a PTP event packet, add the correct filters that will make that future incoming unicast PTP event packets will be timestamped. The unicast address for the filter is gotten from the outgoing skb before sending it. Until now they were not timestamped because only filters that match with the PTP multicast addressed were being configured into the NIC for the PTP special channel. Packets received through different channels are not timestamped, getting "received SYNC without timestamp" error in ptp4l. Note that the inserted filters are never removed unless the NIC is stopped or reconfigured, so efx_ptp_stop is called. Removal of old filters will be handled by the next patch. Additionally, cleanup a bit efx_ptp_xmit_skb_mc to use the reverse xmas tree convention and remove an unnecessary assignment to rc variable in void function. Reported-by:
Yalin Li <yalli@redhat.com> Signed-off-by:
Íñigo Huguet <ihuguet@redhat.com> Reviewed-by:
Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Íñigo Huguet authored
Add a second list for unicast filters and generalize the efx_ptp_insert/remove_filters functions to allow acting in any of the 2 lists. No filters for unicast are inserted yet. That will be done in the next patch. The reason to use 2 different lists instead of a single one is that, in next patches, we will want to check if unicast filters are already added and if they're expired. We don't need that for multicast filters. Reported-by:
-
Íñigo Huguet authored
Instead of using a fixed sized array for the PTP filters, use a list. This is not actually necessary at this point because the filters for multicast PTP are a fixed number, but this is a preparation for the following patches adding support for unicast PTP. To avoid confusion with the new struct type efx_ptp_rxfilter, change the name of some local variables from rxfilter to spec, given they're of the type efx_filter_spec. Reported-by:
-
- 03 Apr, 2023 31 commits
-
-
David S. Miller authored
Daniel Golle says: ==================== net: dsa: add support for MT7988 The MediaTek MT7988 SoC comes with a built-in switch very similar to previous MT7530 and MT7531. However, the switch address space is mapped into the SoCs memory space rather than being connected via MDIO. Using MMIO simplifies register access and also removes the need for a bus lock, and for that reason also makes interrupt handling more light-weight. Note that this is different from previous SoCs like MT7621 and MT7623N which also came with an integrated MT7530-like switch which yet had to be accessed via MDIO. Split-off the part of the driver registering an MDIO driver, then add another module acting as MMIO/platform driver. The whole series has been tested on various MediaTek boards: * MT7623A + MT7530 (BPi-R2) * MT7986A + MT7531 (BPi-R3) * MT7988A reference board Changes since v1: * use 'internal' PHY mode where appropriate * use regmap_update_bits in mt7530_rmw * improve dt-bindings Changes since RFC v3: * WARN_ON_ONCE if register read fails * move probing of the reset GPIO and reset controller link out of common probe function, as they are not actually common Changes since RFC v2: * split into many small commits to ease review * introduce helper functions to reduce code duplication * use helpers for locking to make lock-skipping easier and less ugly to implement. * add dt-bindings for mediatek,mt7988-switch Changes since initial RFC: * use regmap for register access and move register access to bus- specific driver * move initialization of MT7531 SGMII PCS to MDIO driver ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Daniel Golle authored
Add documentation for the built-in switch which can be found in the MediaTek MT7988 SoC. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
-
Daniel Golle authored
Add driver for the built-in Gigabit Ethernet switch which can be found in the MediaTek MT7988 SoC. The switch shares most of its design with MT7530 and MT7531, but has it's registers mapped into the SoCs register space rather than being connected externally or internally via MDIO. Introduce a new platform driver to support that. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Daniel Golle authored
As MT7530 and MT7531 internally use 32-bit wide registers, each access to any register of the switch requires several operations on the MDIO bus. Hence if there is congruent access, e.g. due to PCS or PHY polling, this can mess up and interfere with another ongoing register access sequence. However, the MDIO bus mutex is only relevant for MDIO-connected switches. Prepare switches which have there registers directly mapped into the SoCs register space via MMIO which do not require such locking. There we can simply use regmap's default locking mechanism. Hence guard mutex operations to only be performed in case of MDIO connected switches. Signed-off-by:
-
Daniel Golle authored
Split MT7530 switch driver into a common part and a part specific for MDIO connected switches and multi-chip modules. Move MDIO-specific functions to newly introduced mt7530-mdio.c while keeping the common parts in mt7530.c. Introduce new Kconfig symbol CONFIG_NET_DSA_MT7530_MDIO which is implied by CONFIG_NET_DSA_MT7530. Signed-off-by:
-
Daniel Golle authored
MT7988 shares a significant part of the setup function with MT7531. Split-off those parts into a shared function which is going to be used also by mt7988_setup. Signed-off-by:
-
Daniel Golle authored
Move commonly used parts from mt7530_remove into new mt7530_remove_common helper function which will be used by both, mt7530_remove and the to-be-introduced mt7988_remove. Signed-off-by:
-
Daniel Golle authored
Move commonly used parts from mt7530_probe into new mt7530_probe_common helper function which will be used by both, mt7530_probe and the to-be-introduced mt7988_probe. Signed-off-by:
-
Daniel Golle authored
In preparation of splitting mt7530.c into a driver for MDIO-connected as well as MDIO-accessed built-in switches on one hand and MMIO-accessed built-in switches move the p5_inft_modes() function from mt7530.h to mt7530.c. The function is only needed there and will trigger a compiler warning about a defined but unused function otherwise when including mt7530.h in the to-be-introduced bus-specific drivers. Signed-off-by:
-
Daniel Golle authored
As the MDIO bus lock only needs to be involved if actually operating on an MDIO-connected switch we will need to skip locking for built-in switches which are accessed via MMIO. Create helper functions which simplify that upcoming change. Signed-off-by:
-
Daniel Golle authored
Move creating the SGMII PCS from mt753x_setup() to the more appropriate mt7530_probe() function. This is done also in preparation of moving all functions related to MDIO-connected MT753x switches to a separate module. Signed-off-by:
-
Daniel Golle authored
Use regmap API to access the switch register space. Signed-off-by:
-
Daniel Golle authored
Instead of wrapping the locked register accessor functions, use the unlocked variants and add locking wrapper functions to let regmap handle the locking. This is a preparation towards being able to always use regmap to access switch registers instead of open-coded accessor functions. Signed-off-by:
-
Daniel Golle authored
Instead of macro templates use a dedidated function and allocated regmap_config when creating the regmaps for the pcs-mtk-lynxi instances. This is in preparation to switching to use unlocked regmap accessors and have regmap's locking API handle locking for us. Signed-off-by:
-
Daniel Golle authored
Simply returning the negative error value instead of the read value doesn't seem like a good idea. Return 0 instead and add WARN_ON_ONCE(1) so this kind of error will not go unnoticed. Suggested-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: smsc: add support for edpd tunable This adds support for the EDPD PHY tunable. Per default EDPD is disabled in interrupt mode, the tunable can be used to override this, e.g. if the link partner doesn't use EDPD. The interval to check for energy can be chosen between 1000ms and 2000ms. Note that this value consists of the 1000ms phylib interval for state machine runs plus the time to wait for energy being detected. ==================== Signed-off-by: -
Heiner Kallweit authored
Enable EDPD PHY tunable support for all drivers using lan87xx_read_status. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Heiner Kallweit authored
This adds support for the EDPD PHY tunable. Per default EDPD is disabled in interrupt mode, the tunable can be used to override this, e.g. if the link partner doesn't use EDPD. The interval to check for energy can be chosen between 1000ms and 2000ms. Note that this value consists of the 1000ms phylib interval for state machine runs plus the time to wait for energy being detected. v2: - consider that phylib core holds phydev->lock when calling the phy tunable hooks Signed-off-by:
-
Heiner Kallweit authored
Add a member edpd_max_wait_ms to the private data structure in preparation of making the wait period configurable by supporting the edpd phy tunable. v2: - rename constant to EDPD_MAX_WAIT_DFLT_MS Signed-off-by:
-
Heiner Kallweit authored
Add flag edpd_mode_set_by_user in preparation of adding edpd phy tunable support. This flag will allow users to override the default behavior of edpd being disabled if interrupt mode is used. Signed-off-by:
-
Heiner Kallweit authored
Clear edpd_enable if interupt mode is used, this avoids having to check for PHY_POLL multiple times. Signed-off-by:
-
Heiner Kallweit authored
Add helper smsc_phy_config_edpd() and explicitly clear bit MII_LAN83C185_EDPWRDOWN is edpd_enable isn't set. Boot loader may have left whatever value. Signed-off-by:
-
Heiner Kallweit authored
Rename the flag to edpd_enable, as we're not enabling energy but edpd (energy detect power down) mode. In addition change the type to a bit field member in preparation of adding further flags. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== net: Convert dsa_master_ioctl() to netdev notifier This is preparatory work in order for Maxim Georgiev to be able to start the API conversion process of hardware timestamping from ndo_eth_ioctl() to ndo_hwtstamp_set(): https://lore.kernel.org/netdev/20230331045619.40256-1-glipus@gmail.com/ In turn, Maxim Georgiev's work is a preparation so that Köry Maincent is able to make the active hardware timestamping layer selectable by user space. https://lore.kernel.org/netdev/20230308135936.761794-1-kory.maincent@bootlin.com/ So, quite some dependency chain. Before this patch set, DSA prevented the conversion of any networking driver from the ndo_eth_ioctl() API to the ndo_hwtstamp_set() API, because it wanted to validate the hwtstamping settings on the DSA master, and it was only coded up to do this using the old API. After this patch set, a new netdev notifier exists, which does not depend on anything that would constitute the "soon-to-be-legacy" API, but rather, it uses a newly introduced struct kernel_hwtstamp_config, and it doesn't issue any ioctl at all, being thus compatible both with ndo_eth_ioctl(), and with the not-yet-introduced, but now possible, ndo_hwtstamp_set(). ==================== Signed-off-by:
-
Vladimir Oltean authored
The fact that PTP 2-step TX timestamping is broken on DSA switches if the master also timestamps the same packets is documented by commit f685e609 ("net: dsa: Deny PTP on master if switch supports it"). We attempt to help the users avoid shooting themselves in the foot by making DSA reject the timestamping ioctls on an interface that is a DSA master, and the switch tree beneath it contains switches which are aware of PTP. The only problem is that there isn't an established way of intercepting ndo_eth_ioctl calls, so DSA creates avoidable burden upon the network stack by creating a struct dsa_netdevice_ops with overlaid function pointers that are manually checked from the relevant call sites. There used to be 2 such dsa_netdevice_ops, but now, ndo_eth_ioctl is the only one left. There is an ongoing effort to migrate driver-visible hardware timestamping control from the ndo_eth_ioctl() based API to a new ndo_hwtstamp_set() model, but DSA actively prevents that migration, since dsa_master_ioctl() is currently coded to manually call the master's legacy ndo_eth_ioctl(), and so, whenever a network device driver would be converted to the new API, DSA's restrictions would be circumvented, because any device could be used as a DSA master. The established way for unrelated modules to react on a net device event is via netdevice notifiers. So we create a new notifier which gets called whenever there is an attempt to change hardware timestamping settings on a device. Finally, there is another reason why a netdev notifier will be a good idea, besides strictly DSA, and this has to do with PHY timestamping. With ndo_eth_ioctl(), all MAC drivers must manually call phy_has_hwtstamp() before deciding whether to act upon SIOCSHWTSTAMP, otherwise they must pass this ioctl to the PHY driver via phy_mii_ioctl(). With the new ndo_hwtstamp_set() API, it will be desirable to simply not make any calls into the MAC device driver when timestamping should be performed at the PHY level. But there exist drivers, such as the lan966x switch, which need to install packet traps for PTP regardless of whether they are the layer that provides the hardware timestamps, or the PHY is. That would be impossible to support with the new API. The proposal there, too, is to introduce a netdev notifier which acts as a better cue for switching drivers to add or remove PTP packet traps, than ndo_hwtstamp_set(). The one introduced here "almost" works there as well, except for the fact that packet traps should only be installed if the PHY driver succeeded to enable hardware timestamping, whereas here, we need to deny hardware timestamping on the DSA master before it actually gets enabled. This is why this notifier is called "PRE_", and the notifier that would get used for PHY timestamping and packet traps would be called NETDEV_CHANGE_HWTSTAMP. This isn't a new concept, for example NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER do the same thing. In expectation of future netlink UAPI, we also pass a non-NULL extack pointer to the netdev notifier, and we make DSA populate it with an informative reason for the rejection. To avoid making it go to waste, we make the ioctl-based dev_set_hwtstamp() create a fake extack and print the message to the kernel log. Link: https://lore.kernel.org/netdev/20230401191215.tvveoi3lkawgg6g4@skbuf/ Link: https://lore.kernel.org/netdev/20230310164451.ls7bbs6pdzs4m6pw@skbuf/Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
dsa_master_ioctl() is in the process of getting converted to a different API, where we won't have access to a struct ifreq * anymore, but rather, to a struct kernel_hwtstamp_config. Since ds->ops->port_hwtstamp_get() still uses struct ifreq *, this creates a difficult situation where we have to make up such a dummy pointer. The conversion is a bit messy, because it forces a "good" implementation of ds->ops->port_hwtstamp_get() to return -EFAULT in copy_to_user() because of the NULL ifr->ifr_data pointer. However, it works, and it is only a transient step until ds->ops->port_hwtstamp_get() gets converted to the new API which passes struct kernel_hwtstamp_config and does not call copy_to_user(). Signed-off-by:
-
Vladimir Oltean authored
Jakub Kicinski suggested that we may want to add new UAPI for controlling hardware timestamping through netlink in the future, and in that case, we will be limited to the struct hwtstamp_config that is currently passed in fixed binary format through the SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctls. 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_ethtool_coalesce vs struct ethtool_coalesce. Since struct hwtstamp_config is in include/uapi/linux/net_tstamp.h, here we introduce include/linux/net_tstamp.h which shadows that other header, but also includes it, so that existing includers of this header work as before. In addition to that, we add the definition for the kernel-only structure, and a helper which translates all fields by manual copying. I am doing a manual copy in order to not force the alignment (or type) of the fields of struct kernel_hwtstamp_config to be the same as of struct hwtstamp_config, even though now, they are the same. Link: https://lore.kernel.org/netdev/20230330223519.36ce7d23@kernel.org/Signed-off-by:
-
Vladimir Oltean authored
The kernel will want to start using the more meaningful struct hwtstamp_config pointer in more places, so move the copy_from_user() at the beginning of dev_set_hwtstamp() in order to get to that, and pass this argument to net_hwtstamp_validate(). Signed-off-by:
-
Vladimir Oltean authored
DSA does not want to intercept all ioctls handled by dev_eth_ioctl(), only SIOCSHWTSTAMP. This can be seen from commit f685e609 ("net: dsa: Deny PTP on master if switch supports it"). However, the way in which the dsa_ndo_eth_ioctl() is called would suggest otherwise. Split the handling of SIOCSHWTSTAMP and SIOCGHWTSTAMP ioctls into separate case statements of dev_ifsioc(), and make each one call its own sub-function. This also removes the dsa_ndo_eth_ioctl() call from dev_eth_ioctl(), which from now on exclusively handles PHY ioctls. Signed-off-by:
-
Vladimir Oltean authored
In the expression "x == 0 || x != -95", the term "x == 0" does not change the expression's logical value, because 0 != -95, and so, if x is 0, the expression would still be true by virtue of the second term. If x is non-zero, the expression depends on the truth value of the second term anyway. As such, the first term is redundant and can be deleted. Signed-off-by:
-
Vladimir Oltean authored
The "switch (cmd)" block from dev_ifsioc() gained a bit too much unnecessary manual handling of "cmd" in the "default" case, starting with the private ioctls. Clean that up by using the "ellipsis" gcc extension, adding separate cases for the rest of the ioctls, and letting the default case only return -EINVAL. Signed-off-by:
-
- 02 Apr, 2023 6 commits
-
-
Tom Rix authored
clang with W=1 reports drivers/net/ethernet/alteon/acenic.c:2438:10: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable] int i, len = 0; ^ This variable is not used so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: Use static trip points for transceiver modules Ido Schimmel writes: See patch #1 for motivation and implementation details. Patches #2-#3 are simple cleanups as a result of the changes in the first patch. ==================== Signed-off-by: -
Ido Schimmel authored
The get_temp() callback of a thermal zone associated with a transceiver module no longer needs to read the temperature thresholds of the module. Therefore, simplify the callback by only reading the temperature. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Vadim Pasternak <vadimp@nvidia.com> Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
-
Ido Schimmel authored
The function can no longer fail so make it void and remove the associated error path. Signed-off-by:
-
Ido Schimmel authored
The driver registers a thermal zone for each transceiver module and tries to set the trip point temperatures according to the thresholds read from the transceiver. If a threshold cannot be read or if a transceiver is unplugged, the trip point temperature is set to zero, which means that it is disabled as far as the thermal subsystem is concerned. A recent change in the thermal core made it so that such trip points are no longer marked as disabled, which lead the thermal subsystem to incorrectly set the associated cooling devices to the their maximum state [1]. A fix to restore this behavior was merged in commit f1b80a38 ("thermal: core: Restore behavior regarding invalid trip points"). However, the thermal maintainer suggested to not rely on this behavior and instead always register a valid array of trip points [2]. Therefore, create a static array of trip points with sane defaults (suggested by Vadim) and register it with the thermal zone of each transceiver module. User space can choose to override these defaults using the thermal zone sysfs interface since these files are writeable. Before: $ cat /sys/class/thermal/thermal_zone11/type mlxsw-module11 $ cat /sys/class/thermal/thermal_zone11/trip_point_*_temp 65000 75000 80000 After: $ cat /sys/class/thermal/thermal_zone11/type mlxsw-module11 $ cat /sys/class/thermal/thermal_zone11/trip_point_*_temp 55000 65000 80000 Also tested by reverting commit f1b80a38 ("thermal: core: Restore behavior regarding invalid trip points") and making sure that the associated cooling devices are not set to their maximum state. [1] https://lore.kernel.org/linux-pm/ZA3CFNhU4AbtsP4G@shredder/ [2] https://lore.kernel.org/linux-pm/f78e6b70-a963-c0ca-a4b2-0d4c6aeef1fb@linaro.org/Signed-off-by:
-
Jakub Kicinski authored
napi_id is read by GRO and drivers to mark skbs, and it currently sits at the end of the structure, in a mostly unused cache line. Move it up into a hole, and separate the clearly control path fields from the important ones. Before: struct napi_struct { struct list_head poll_list; /* 0 16 */ long unsigned int state; /* 16 8 */ int weight; /* 24 4 */ int defer_hard_irqs_count; /* 28 4 */ long unsigned int gro_bitmask; /* 32 8 */ int (*poll)(struct napi_struct *, int); /* 40 8 */ int poll_owner; /* 48 4 */ /* XXX 4 bytes hole, try to pack */ struct net_device * dev; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct gro_list gro_hash[8]; /* 64 192 */ /* --- cacheline 4 boundary (256 bytes) --- */ struct sk_buff * skb; /* 256 8 */ struct list_head rx_list; /* 264 16 */ int rx_count; /* 280 4 */ /* XXX 4 bytes hole, try to pack */ struct hrtimer timer; /* 288 64 */ /* XXX last struct has 4 bytes of padding */ /* --- cacheline 5 boundary (320 bytes) was 32 bytes ago --- */ struct list_head dev_list; /* 352 16 */ struct hlist_node napi_hash_node; /* 368 16 */ /* --- cacheline 6 boundary (384 bytes) --- */ unsigned int napi_id; /* 384 4 */ /* XXX 4 bytes hole, try to pack */ struct task_struct * thread; /* 392 8 */ /* size: 400, cachelines: 7, members: 17 */ /* sum members: 388, holes: 3, sum holes: 12 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 16 bytes */ }; After: struct napi_struct { struct list_head poll_list; /* 0 16 */ long unsigned int state; /* 16 8 */ int weight; /* 24 4 */ int defer_hard_irqs_count; /* 28 4 */ long unsigned int gro_bitmask; /* 32 8 */ int (*poll)(struct napi_struct *, int); /* 40 8 */ int poll_owner; /* 48 4 */ /* XXX 4 bytes hole, try to pack */ struct net_device * dev; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct gro_list gro_hash[8]; /* 64 192 */ /* --- cacheline 4 boundary (256 bytes) --- */ struct sk_buff * skb; /* 256 8 */ struct list_head rx_list; /* 264 16 */ int rx_count; /* 280 4 */ unsigned int napi_id; /* 284 4 */ struct hrtimer timer; /* 288 64 */ /* XXX last struct has 4 bytes of padding */ /* --- cacheline 5 boundary (320 bytes) was 32 bytes ago --- */ struct task_struct * thread; /* 352 8 */ struct list_head dev_list; /* 360 16 */ struct hlist_node napi_hash_node; /* 376 16 */ /* size: 392, cachelines: 7, members: 17 */ /* sum members: 388, holes: 1, sum holes: 4 */ /* paddings: 1, sum paddings: 4 */ /* forced alignments: 1 */ /* last cacheline: 8 bytes */ } __attribute__((__aligned__(8))); Signed-off-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
-
