- 14 Feb, 2023 6 commits
-
-
Uwe Kleine-König authored
The function returns zero unconditionally. Change it to return void instead which simplifies some callers as error handing becomes unnecessary. This also makes it more obvious that most platform remove callbacks always return zero. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230211112431.214252-1-u.kleine-koenig@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Lorenzo Bianconi authored
Devices with hardware buffer management do not support XDP, so do not set xdp_features for them. Fixes: 66c0e13a ("drivers: net: turn on XDP features") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/19b5838bb3e4515750af822edb2fa5e974d0a86b.1676196230.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Add missing ndo_xdp_xmit bit to xdp_features capability flag. Fixes: 66c0e13a ("drivers: net: turn on XDP features") Signed-off-by:
-
Lorenzo Bianconi authored
Add missing xsk zero-copy bit to xdp_features capability flag. Fixes: 66c0e13a ("drivers: net: turn on XDP features") Signed-off-by:
-
Christophe JAILLET authored
dma_alloc_coherent() already clears the allocated memory, there is no need to explicitly call memset(). Moreover, it is likely that the size in the memset() is incorrect and should be "size * sizeof(*ring->desc)". Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/d5acce7dd108887832c9719f62c7201b4c83b3fb.1676184599.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Lorenzo Bianconi authored
Set xdp_features netdevice flag if lan966x nic supports xdp mode. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/01f4412f28899d97b0054c9c1a63694201301b42.1676055718.git.lorenzo@kernel.orgSigned-off-by:
-
- 13 Feb, 2023 34 commits
-
-
David S. Miller authored
Oleksij Rempel says: ==================== net: add EEE support for KSZ9477 switch family changes v8: - fix comment for linkmode_to_mii_eee_cap1_t() function - add Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> - add Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> changes v7: - update documentation for genphy_c45_eee_is_active() - address review comments on "net: dsa: microchip: enable EEE support" patch changes v6: - split patch set and send only first 9 patches - Add Reviewed-by: Andrew Lunn <andrew@lunn.ch> - use 0xffff instead of GENMASK - Document @supported_eee - use "()" with function name in comments changes v5: - spell fixes - move part of genphy_c45_read_eee_abilities() to genphy_c45_read_eee_cap1() - validate MDIO_PCS_EEE_ABLE register against 0xffff val. - rename *eee_100_10000* to *eee_cap1* - use linkmode_intersects(phydev->supported, PHY_EEE_CAP1_FEATURES) instead of !linkmode_empty() - add documentation to linkmode/register helpers changes v4: - remove following helpers: mmd_eee_cap_to_ethtool_sup_t mmd_eee_adv_to_ethtool_adv_t ethtool_adv_to_mmd_eee_adv_t and port drivers from this helpers to linkmode helpers. - rebase against latest net-next - port phy_init_eee() to genphy_c45_eee_is_active() changes v3: - rework some parts of EEE infrastructure and move it to c45 code. - add supported_eee storage and start using it in EEE code and by the micrel driver. - add EEE support for ar8035 PHY - add SmartEEE support to FEC i.MX series. changes v2: - use phydev->supported instead of reading MII_BMSR regiaster - fix @get_eee > @set_eee With this patch series we provide EEE control for KSZ9477 family of switches and AR8035 with i.MX6 configuration. According to my tests, on a system with KSZ8563 switch and 100Mbit idle link, we consume 0,192W less power per port if EEE is enabled. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Oleksij Rempel authored
All preparations are done. Now we can start using new functions and remove the old code. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Oleksij Rempel authored
Reduce code duplicated by migrating phy_init_eee() to genphy_c45_eee_is_active(). Signed-off-by:
-
Oleksij Rempel authored
Migrate from genphy_config_eee_advert() to genphy_c45_write_eee_adv(). It should work as before except write operation to the EEE adv registers will be done only if some EEE abilities was detected. If some driver will have a regression, related driver should provide own .get_features callback. See micrel.c:ksz9477_get_features() as example. Signed-off-by:
-
Oleksij Rempel authored
Migrate from genphy_config_eee_advert() to genphy_c45_write_eee_adv(). It should work as before except write operation to the EEE adv registers will be done only if some EEE abilities was detected. If some driver will have a regression, related driver should provide own .get_features callback. See micrel.c:ksz9477_get_features() as example. Signed-off-by:
-
Oleksij Rempel authored
Add replacement for phy_ethtool_get/set_eee() functions. Current phy_ethtool_get/set_eee() implementation is great and it is possible to make it even better: - this functionality is for devices implementing parts of IEEE 802.3 specification beyond Clause 22. The better place for this code is phy-c45.c - currently it is able to do read/write operations on PHYs with different abilities to not existing registers. It is better to use stored supported_eee abilities to avoid false read/write operations. - the eee_active detection will provide wrong results on not supported link modes. It is better to validate speed/duplex properties against supported EEE link modes. - it is able to support only limited amount of link modes. We have more EEE link modes... By refactoring this code I address most of this point except of the last one. Adding additional EEE link modes will need more work. Signed-off-by:
-
Oleksij Rempel authored
This function will be needed for genphy_c45_ethtool_get_eee() provided by next patch. Signed-off-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
-
Oleksij Rempel authored
KSZ8563R, which has same PHYID as KSZ9477 family, will change "EEE control and capability 1" (Register 3.20) content depending on configuration of "EEE advertisement 1" (Register 7.60). Changes on the 7.60 will affect 3.20 register. So, instead of depending on register 3.20, driver should set supported_eee. Proper supported_eee configuration is needed to make use of generic PHY c45 set/get_eee functions provided by next patches. Signed-off-by:
-
Oleksij Rempel authored
Add generic function for EEE abilities defined by IEEE 802.3 specification. For now following registers are supported: - IEEE 802.3-2018 45.2.3.10 EEE control and capability 1 (Register 3.20) - IEEE 802.3cg-2019 45.2.1.186b 10BASE-T1L PMA status register (Register 1.2295) Since I was not able to find any flag signaling support of these registers, we should detect link mode abilities first and then based on these abilities doing EEE link modes detection. Results of EEE ability detection will be stored into new variable phydev->supported_eee. Signed-off-by:
-
Oleksij Rempel authored
Some of KSZ9477 family switches provides EEE support. To enable it, we just need to register set_mac_eee/set_mac_eee handlers and validate supported chip version and port. Currently supported chip variants are: KSZ8563, KSZ9477, KSZ9563, KSZ9567, KSZ9893, KSZ9896, KSZ9897. KSZ8563 supports EEE only with 100BaseTX/Full. Other chips support 100BaseTX/Full and 1000BaseTX/Full. Low Power Idle configuration is not supported and currently not documented in the datasheets. EEE PHY specific tunings are not documented in the switch datasheets, but can overlap with KSZ9131 specification. Signed-off-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: on-chip descriptors We start with a couple of house-keeping patches that were originally presented for 'net', then we add support for on-chip descriptor rings for tx-push, as well as adding support for rx-push. I have a patch for the ethtool userland utility that I can send out once this has been accepted. v4: added rx-push attributes to ethtool netlink converted CMB feature from using a priv-flag to using ethtool tx/rx-push v3: edited commit message to describe interface-down limitation added warn msg if cmb_inuse alloc fails removed unnecessary clearing of phy_cmb_pages and cmb_npages changed cmb_rings_toggle to use cmb_inuse removed unrelated pci_set_drvdata() removed unnecessary (u32) cast added static inline func for writing CMB descriptors v2: dropped the rx buffers patch ==================== Signed-off-by: -
Shannon Nelson authored
The ionic device has on-board memory (CMB) that can be used for descriptors as a way to speed descriptor access for faster packet processing. It is rumored to improve latency and/or packets-per-second for some profiles of small packet traffic, although your mileage may vary. Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Signed-off-by:
-
Shannon Nelson authored
Similar to what was done for TX_PUSH, add an RX_PUSH concept to the ethtool interfaces. Signed-off-by:
-
Shannon Nelson authored
Minor Code cleanup details. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Shannon Nelson authored
We have the pointer already, don't need to go through the lif struct for it. Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: determine GSI register offsets differently This series changes the way GSI register offset are specified, using the "reg" mechanism currently used for IPA registers. A follow-on series will extend this work so fields within GSI registers are also specified this way. The first patch rearranges the GSI register initialization code so it is similar to the way it's done for the IPA registers. The second identifies all the GSI registers in an enumerated type. The third introduces "gsi_reg-v3.1.c" and uses the "reg" code to define one GSI register offset. The second-to-last patch just adds "gsi_reg-v3.5.1.c", because that version introduces a new register not previously defined. All the rest just define the rest of the GSI register offsets using the "reg" mechanism. Note that, to have continued lines align with an open parenthesis, new files created in this series cause some checkpatch warnings. ==================== Signed-off-by: -
Alex Elder authored
Add the remaining GSI register offset definitions. Use gsi_reg() rather than the corresponding GSI_*_OFFSET() macros to get the offsets for these registers, and get rid of the macros. Note that we are now defining information for the HW_PARAM_2 register, and that doesn't appear until IPA v3.5.1. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The next patch adds a GSI register field that is only valid starting at IPA v3.5.1. Create "gsi_v3.5.1.c" from "gsi_v3.1.c", changing only the name of the public regs structure it defines. Signed-off-by:
-
Alex Elder authored
Add definitions of the offsets for IRQ-related GSI registers. Use gsi_reg() rather than the corresponding GSI_CNTXT_*_OFFSET() macros to get the offsets for these registers, and get rid of the macros. Signed-off-by:
-
Alex Elder authored
Add definitions of the offsets and strides for registers whose offset depends on an event ring ID, and use gsi_reg() and its returned value to determine offsets for these registers. Get rid of the corresponding GSI_EV_CH_E_*_OFFSET() macros. Signed-off-by:
-
Alex Elder authored
Continue populating with GSI register definitions, adding remaining registers whose offset depends on a channel ID. Use gsi_reg() and reg_n_offset() to determine offsets for those registers, and get rid of the corresponding GSI_CH_C_*_OFFSET() macros. Signed-off-by:
-
Alex Elder authored
Create a new register definition file in the "reg" subdirectory, and begin populating it with GSI register definitions based on IPA version. The GSI registers haven't changed much, so several IPA versions can share the same GSI register definitions. As with IPA registers, an array of pointers indexed by GSI register ID refers to these register definitions, and a new "regs" field in the GSI structure is initialized in gsi_reg_init() to refer to register information based on the IPA version (though for now there's only one). The new function gsi_reg() returns register information for a given GSI register, and the result can be used to look up that register's offset. This patch is meant only to put the infrastructure in place, so only eon register (CH_C_QOS) is defined for each version, and only the offset and stride are defined for that register. Use new function gsi_reg() to look up that register's information to get its offset, This makes the GSI_CH_C_QOS_OFFSET() unnecessary, so get rid of it. Signed-off-by:
-
Alex Elder authored
Create a new gsi_reg_id enumerated type, which identifies each GSI register with a symbolic identifier. Create a function that indicates whether a register ID is valid. Signed-off-by:
-
Alex Elder authored
Create a new source file "gsi_reg.c", and in it, introduce a new function to encapsulate initializing GSI registers, including looking up and I/O mapping their memory. Create gsi_reg_exit() as the inverse of the init function. Signed-off-by:
-
Eric Dumazet authored
If TCA_STAB attribute is malformed, qdisc_get_stab() returns an error, and we end up calling ops->destroy() while ops->init() has not been called yet. While we are at it, call qdisc_put_stab() after ops->destroy(). Fixes: 1f62879e ("net/sched: make stab available before ops->init() call") Reported-by: syzbot+d44d88f1d11e6ca8576b@syzkaller.appspotmail.com Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Horatiu Vultur authored
Add support for PHC and timestamping operations for the lan8841 PHY. PTP 1-step and 2-step modes are supported, over Ethernet and UDP both ipv4 and ipv6. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== devlink: params cleanups and devl_param_driverinit_value_get() fix The primary motivation of this patchset is the patch #6, which fixes an issue introduced by 075935f0 ("devlink: protect devlink param list by instance lock") and reported by Kim Phillips <kim.phillips@amd.com> (https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/) and my colleagues doing mlx5 driver regression testing. The basis idea is that devl_param_driverinit_value_get() could be possible to the called without holding devlink intance lock in most of the cases (all existing ones in the current codebase), which would fix some mlx5 flows where the lock is not held. To achieve that, make sure that the param value does not change between reloads with patch #2. Also, convert the param list to xarray which removes the worry about list_head consistency when doing lockless lookup. The rest of the patches are doing some small related cleanup of things that poke me in the eye during the work. --- v1->v2: - a small bug was fixed in patch #2, the rest of the code stays the same so I left review/ack tags attached to them ==================== Signed-off-by:
-
Jiri Pirko authored
Driver calling devl_param_driverinit_value_set() has to hold devlink instance lock while doing that. Put an assertion there. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Jiri Pirko authored
If the driver maintains following basic sane behavior, the devl_param_driverinit_value_get() function could be called without holding instance lock: 1) Driver ensures a call to devl_param_driverinit_value_get() cannot race with registering/unregistering the parameter with the same parameter ID. 2) Driver ensures a call to devl_param_driverinit_value_get() cannot race with devl_param_driverinit_value_set() call with the same parameter ID. 3) Driver ensures a call to devl_param_driverinit_value_get() cannot race with reload operation. By the nature of params usage, these requirements should be trivially achievable. If the driver for some off reason is not able to comply, it has to take the devlink->lock while calling devl_param_driverinit_value_get(). Remove the lock assertion and add comment describing the locking requirements. This fixes a splat in mlx5 driver introduced by the commit referenced in the "Fixes" tag. Lore: https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/Reported-by:
Kim Phillips <kim.phillips@amd.com> Fixes: 075935f0 ("devlink: protect devlink param list by instance lock") Signed-off-by:
-
Jiri Pirko authored
Loose the linked list for params and use xarray instead. Note that this is required to be eventually possible to call devl_param_driverinit_value_get() without holding instance lock. Signed-off-by:
-
Jiri Pirko authored
As xarray has an iterator helper that allows to start from specified index, use this directly and avoid repeated iteration from 0. Signed-off-by:
-
Jiri Pirko authored
Probably due to copy-paste error, the name of the arg is "init_val" which is misleading, as the pointer is used to point to struct where to store the current value. Rename it to "val" and change the arg comment a bit on the way. Signed-off-by:
-
Jiri Pirko authored
The driverinit param purpose is to serve the driver during init/reload time to provide a value, either default or set by user. Make sure that driver does not read value updated by user before the reload is performed. Hold the new value in a separate struct and switch it during reload. Note that this is required to be eventually possible to call devl_param_driverinit_value_get() without holding instance lock. Signed-off-by:
-
Jiri Pirko authored
No need to treat string params any different comparing to other types. Rely on the struct assign to copy the whole struct, including the string. Signed-off-by:
-
