- 11 Jan, 2023 6 commits
-
-
Tariq Toukan authored
Add TLS debugfs to improve observability by exposing the size of the tls TX pool. To observe the size of the TX pool: $ cat /sys/kernel/debug/mlx5/<pci>/nic/tls/tx/pool_size Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Co-developed-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Gal Pressman authored
Similar to the mlx5_core debugfs, lay the groundwork for mlx5e debugfs files under /sys/kernel/debug/mlx5/<pci>/nic/.. Signed-off-by:
-
Maher Sanalla authored
Currently, the user can modify device's receive buffer size, modify the mapping between QoS priority groups to buffers and change the buffer state to become lossy/lossless via pfc command. However, the shared receive buffer pool alignments, as a result of such commands, is performed only when the shared buffer is in FW ownership. When a user changes the mapping of priority groups or buffer size, the shared buffer is moved to SW ownership. Therefore, for devices that support shared buffer, handle the shared buffer alignments in accordance to user's desired configurations. Meaning, the following will be performed: 1. For every change of buffer's headroom, recalculate the size of shared buffer to be equal to "total_buffer_size" - "new_headroom_size". The new shared buffer size will be split in ratio of 3:1 between lossy and lossless pools, respectively. 2. For each port buffer change, count the number of lossless buffers. If there is only one lossless buffer, then set its lossless pool usage threshold to be infinite. Otherwise, if there is more than one lossless buffer, set a usage threshold for each lossless buffer. While at it, add more verbosity to debug prints when handling user commands, to assist in future debug. Signed-off-by:
Maher Sanalla <msanalla@nvidia.com> Reviewed-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Maher Sanalla authored
To allow users to configure shared receive buffer parameters through dcbnl callbacks, expose an API to query and modify SBPR and SBCM registers, which will be used in the upcoming patch. Signed-off-by:
-
Maher Sanalla authored
Add the shared receive buffer management and configuration registers: 1. SBPR - Shared Buffer Pools Register 2. SBCM - Shared Buffer Class Management Register Signed-off-by:
-
Dai Shixin authored
Fix a typo of "permision" which should be "permission". Signed-off-by:
Dai Shixin <dai.shixin@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com.cn> Link: https://lore.kernel.org/r/202301091935262709751@zte.com.cnSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 10 Jan, 2023 23 commits
-
-
Jakub Kicinski authored
Michael Walle says: ==================== net: mdio: Start separating C22 and C45 This patch set starts the separation of C22 and C45 MDIO bus transactions at the API level to the MDIO Bus drivers. C45 read and write ops are added to the MDIO bus driver structure, and the MDIO core will try to use these ops if requested to perform a C45 transfer. If not available a fallback to the older API is made, to allow backwards compatibility until all drivers are converted. A few drivers are then converted to this new API. The core DSA patch was dropped for now as there is still an ongoing discussion. It will be picked up in a later series again. v2: https://lore.kernel.org/r/20221227-v6-2-rc1-c45-seperation-v2-0-ddb37710e5a7@walle.cc v1: https://lore.kernel.org/r/20220508153049.427227-1-andrew@lunn.ch ==================== Link: https://lore.kernel.org/r/20221227-v6-2-rc1-c45-seperation-v3-0-ade1deb438da@walle.ccSigned-off-by:
-
Andrew Lunn authored
The global2 SMI MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Update the SERDES code to make use of these new accessors. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Andrew Lunn authored
Some DSA devices pass through PHY access to the MDIO bus the switch is on. Add C45 versions of the current C22 helpers for nested accesses to MDIO busses, so that C22 and C45 can be separated in these DSA drivers. Signed-off-by:
-
Andrew Lunn authored
The fec MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Signed-off-by:
Wei Fang <wei.fang@nxp.com> Signed-off-by:
-
Andrew Lunn authored
The xgmac MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. While at it, remove the misleading comment. According to Vladimir Oltean: - miimcom is a register accessed by fsl_pq_mdio.c, not by xgmac_mdio.c - "device dev" doesn't really refer to anything (maybe "dev_addr"). - I don't understand what is meant by the comment "All PHY configuration has to be done through the TSEC1 MIIM regs". Or rather said, I think I understand, but it is irrelevant to the driver for 2 reasons: * TSEC devices use the fsl_pq_mdio.c driver, not this one * It doesn't matter to this driver whose TSEC registers are used for MDIO access. The driver just works with the registers it's given, which is a concern for the device tree. - barring the above, the rest just describes the MDIO bus API, which is superfluous Signed-off-by: -
Andrew Lunn authored
The marvell MDIO driver supports two different hardware blocks. The XSMI block is C45 only. Convert this block to the new API, and only populate the c45 calls in the bus structure. Signed-off-by:
-
Andrew Lunn authored
The bitbbanging bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new driver API calls. The SH Ethernet driver places wrappers around these functions. In order to not break boards which might be using C45, add similar wrappers for C45 operations. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Andrew Lunn authored
Now that mdiobus_c45_addr() is only used within the MDIO code during fallback, move the function next to its only users. This function should not be used any more in drivers, the c45 helpers should be used in its place, so hiding it away will prevent any new users from being added. Signed-off-by:
-
Andrew Lunn authored
When performing a C22 operation, check that the bus driver actually provides the methods, and return -EOPNOTSUPP if not. C45 only busses do exist, and in future their C22 methods will be NULL. Signed-off-by:
-
Andrew Lunn authored
Now that C45 uses its own read/write methods, the validation performed when a bus is registers needs updating. All combinations of C22 and C45 are supported, but both read and write methods must be provided, read only busses are not supported etc. Signed-off-by:
-
Andrew Lunn authored
Convert the PCS-XPCS driver to make use of the C45 MDIO bus API for modify_change(). Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Currently C22 and C45 transactions are mixed over a combined API calls which make use of a special bit in the reg address to indicate if a C45 transaction should be performed. This makes it impossible to know if the bus driver actually supports C45. Additionally, many C22 only drivers don't return -EOPNOTSUPP when asked to perform a C45 transaction, they mistaking perform a C22 transaction. This is the first step to cleanly separate C22 from C45. To maintain backwards compatibility until all drivers which are capable of performing C45 are converted to this new API, the helper functions will fall back to the older API if the new API is not supported. Eventually this fallback will be removed. Signed-off-by:
-
Paolo Abeni authored
Michael Walle says: ==================== net: phy: mxl-gpy: broken interrupt fixes The GPY215 has a broken interrupt pin. This patch series tries to workaround that and because in general that is not possible, disables the interrupts by default and falls back to polling mode. There is an opt-in via the devicetree. ==================== Link: https://lore.kernel.org/r/20230109123013.3094144-1-michael@walle.ccSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Michael Walle authored
The interrupts on the GPY215B and GPY215C are broken and the only viable fix is to disable them altogether. There is still the possibilty to opt-in via the device tree. Signed-off-by:
-
Michael Walle authored
Until now, it is not possible for a PHY driver to disable interrupts during runtime. If a driver offers the .config_intr() as well as the .handle_interrupt() ops, it is eligible for interrupt handling. Introduce a new flag for the dev_flags property of struct phy_device, which can be set by PHY driver to skip interrupt setup and fall back to polling mode. At the moment, this is used for the MaxLinear PHY which has broken interrupt handling and there is a need to disable interrupts in some cases. Signed-off-by:
-
Michael Walle authored
Add the device tree bindings for the MaxLinear GPY2xx PHYs, which essentially adds just one flag: maxlinear,use-broken-interrupts. One might argue, that if interrupts are broken, just don't use the interrupt property in the first place. But it needs to be more nuanced. First, this interrupt line is also used to wake up systems by WoL, which has nothing to do with the (broken) PHY interrupt handling. Second and more importantly, there are devicetrees which have this property set. Thus, within the driver we have to switch off interrupt handling by default as a workaround. But OTOH, a systems designer who knows the hardware and knows there are no shared interrupts for example, can use this new property as a hint to the driver that it can enable the interrupt nonetheless. Signed-off-by:
-
Michael Walle authored
MaxLinear is a manufacturer of integrated circuits. https://www.maxlinear.comSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Paolo Abeni authored
Hans J. Schultz says: ==================== mv88e6xxx: Add MAB offload support This patch-set adds MAB [1] offload support in mv88e6xxx. Patch #1: Correct default return value for mv88e6xxx_port_bridge_flags. Patch #2: Shorten the locked section in mv88e6xxx_g1_atu_prob_irq_thread_fn(). Patch #3: The MAB implementation for mv88e6xxx. [1] https://git.kernel.org/netdev/net-next/c/4bf24ad09bc0 ==================== Link: https://lore.kernel.org/r/20230108094849.1789162-1-netdev@kapio-technology.comSigned-off-by: -
Hans J. Schultz authored
This implementation for the Marvell mv88e6xxx chip series is based on handling ATU miss violations occurring when packets ingress on a port that is locked with learning on. This will trigger a SWITCHDEV_FDB_ADD_TO_BRIDGE event, which will result in the bridge module adding a locked FDB entry. This bridge FDB entry will not age out as it has the extern_learn flag set. Userspace daemons can listen to these events and either accept or deny access for the host, by either replacing the locked FDB entry with a simple entry or leave the locked entry. If the host MAC address is already present on another port, a ATU member violation will occur, but to no real effect, and the packet will be dropped in hardware. Statistics on these violations can be shown with the command and example output of interest: ethtool -S ethX NIC statistics: ... atu_member_violation: 5 atu_miss_violation: 23 ... Where ethX is the interface of the MAB enabled port. Furthermore, as added vlan interfaces where the vid is not added to the VTU will cause ATU miss violations reporting the FID as MV88E6XXX_FID_STANDALONE, we need to check and skip the miss violations handling in this case. Signed-off-by:Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Hans J. Schultz authored
As only the hardware access functions up til and including mv88e6xxx_g1_atu_mac_read() called under the interrupt handler need to take the chip lock, we release the chip lock after this call. The follow up code that handles the violations can run without the chip lock held. In further patches, the violation handler function will even be incompatible with having the chip lock held. This due to an AB/BA ordering inversion with rtnl_lock(). Signed-off-by:
-
Hans J. Schultz authored
The default return value -EOPNOTSUPP of mv88e6xxx_port_bridge_flags() came from the return value of the DSA method port_egress_floods() in commit 4f85901f ("net: dsa: mv88e6xxx: add support for bridge flags"), but the DSA API was changed in commit a8b659e7 ("net: dsa: act as passthrough for bridge port flags"), resulting in the return value -EOPNOTSUPP not being valid anymore, and sections for new flags will not need to set the return value to zero on success, as with the new mab flag added in a following patch. Signed-off-by:
-
Raju Rangoju authored
Add the necessary changes to support 10 Mbps speed for BaseT and SFP port modes. This is supported in MAC ver >= 30H. Signed-off-by:
Raju Rangoju <Raju.Rangoju@amd.com> Link: https://lore.kernel.org/r/20230109101819.747572-1-Raju.Rangoju@amd.comSigned-off-by:
-
Jamie Gloudon authored
This enables link partner advertised support to show link modes and pause frame use. Signed-off-by:
Jamie Gloudon <jamie.gloudon@gmx.fr> Tested-by:
Naama Meir <naamax.meir@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by:
-
- 09 Jan, 2023 11 commits
-
-
Jakub Kicinski authored
Since commit ce098da1 ("skbuff: Introduce slab_build_skb()") drivers trying to build skb around slab-backed buffers should go via slab_build_skb() rather than passing frag_size = 0 to the main build_skb(). Remove the copy'n'pasted comments about 0 meaning slab. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjørn Mork says: ==================== r8152: allow firmwares with NCM support Some device and firmware combinations with NCM support will end up using the cdc_ncm driver by default. This is sub- optimal for the same reasons we've previously accepted the blacklist hack in cdc_ether. The recent support for subclassing the generic USB device driver allows us to create a very slim driver with the same functionality. This patch set uses that to implement a device specific configuration default which is independent of any USB interface drivers. This means that it works equally whether the device initially ends up in NCM or ECM mode, without depending on any code in the respective class drivers. ==================== Signed-off-by: -
Bjørn Mork authored
The r8152 driver does not need this anymore. Dropping blacklist entries adds optional support for these devices in ECM mode. The 8153 devices are handled by the r8153_ecm driver when in ECM mode, and must still be blacklisted here. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
Subclassing the generic USB device driver to override the default configuration selection regardless of matching interface drivers. The r815x family devices expose a vendor specific function which the r8152 interface driver wants to handle. This is the preferred device mode. Additionally one or more USB class functions are usually supported for hosts lacking a vendor specific driver. The choice is USB configuration based, with one alternate function per configuration. Example device with both NCM and ECM alternate cfgs: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 3 P: Vendor=0bda ProdID=8156 Rev=31.00 S: Manufacturer=Realtek S: Product=USB 10/100/1G/2.5G LAN S: SerialNumber=001000001 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=256mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=00 Driver=r8152 E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=128ms C: #Ifs= 2 Cfg#= 2 Atr=a0 MxPwr=256mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=128ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms C: #Ifs= 2 Cfg#= 3 Atr=a0 MxPwr=256mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=128ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms A problem with this is that Linux will prefer class functions over vendor specific functions. Using the above example, Linux defaults to cfg #2, running the device in a sub-optimal NCM mode. Previously we've attempted to work around the problem by blacklisting the devices in the ECM class driver "cdc_ether", and matching on the ECM class function in the vendor specific interface driver. The latter has been used to switch back to the vendor specific configuration when the driver is probed for a class function. This workaround has several issues; - class driver blacklists is additional maintanence cruft in an unrelated driver - class driver blacklists prevents users from optionally running the devices in class mode - each device needs double match entries in the vendor driver - the initial probing as a class function slows down device discovery Now these issues have become even worse with the introduction of firmware supporting both NCM and ECM, where NCM ends up as the default mode in Linux. To use the same workaround, we now have to blacklist the devices in to two different class drivers and add yet another match entry to the vendor specific driver. This patch implements an alternative workaround strategy - independent of the interface drivers. It avoids adding a blacklist to the cdc_ncm driver and will let us remove the existing blacklist from the cdc_ether driver. As an additional bonus, removing the blacklists allow users to select one of the other device modes if wanted. Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Protocol in-use tracking and code cleanup Here's a collection of commits from the MPTCP tree: Patches 1-4 and 6 contain miscellaneous code cleanup for more consistent use of helper functions, existing local variables, and better naming. Patches 5, 7, and 9 add sock_prot_inuse tracking for MPTCP and an associated self test. Patch 8 modifies the mptcp_connect self test tool to exit on SIGUSR1 when in "slow mode". ==================== Signed-off-by: -
Menglong Dong authored
Add the function chk_msk_inuse() to diag.sh, which is used to check the statistics of mptcp socket in use. As mptcp socket in listen state will be closed randomly after 'accept', we need to get the count of listening mptcp socket through 'ss' command. All tests pass. Acked-by:
Menglong Dong <imagedong@tencent.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Menglong Dong authored
For now, mptcp_connect won't exit after receiving the 'SIGUSR1' signal if '-r' is set. Fix this by skipping poll and sleep in copyfd_io_poll() if 'quit' is set. Acked-by:
-
Menglong Dong authored
Do the statistics of mptcp socket in use with sock_prot_inuse_add(). Therefore, we can get the count of used mptcp socket from /proc/net/protocols: & cat /proc/net/protocols protocol size sockets memory press maxhdr slab module cl co di ac io in de sh ss gs se re sp bi br ha uh gp em MPTCPv6 2048 0 0 no 0 yes kernel y n y y y y y y y y y y n n n y y y n MPTCP 1896 1 0 no 0 yes kernel y n y y y y y y y y y y n n n y y y n Acked-by:
-
Menglong Dong authored
'ssk' should be more appropriate to be the name of the first argument in mptcp_token_new_connect(). Acked-by:
-
Menglong Dong authored
The 'sk_prot' field in token KUNIT self-tests will be dereferenced in mptcp_token_new_connect(). Therefore, init it with tcp_prot. Acked-by:
-
Menglong Dong authored
'sock->sk' is used frequently in mptcp_listen(). Therefore, we can introduce the 'sk' and replace 'sock->sk' with it. Acked-by:
-
