- 17 Jun, 2024 7 commits
-
-
D. Wythe authored
This patch allows to create smc socket via AF_INET, similar to the following code, /* create v4 smc sock */ v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC); /* create v6 smc sock */ v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_SMC); There are several reasons why we believe it is appropriate here: 1. For smc sockets, it actually use IPv4 (AF-INET) or IPv6 (AF-INET6) address. There is no AF_SMC address at all. 2. Create smc socket in the AF_INET(6) path, which allows us to reuse the infrastructure of AF_INET(6) path, such as common ebpf hooks. Otherwise, smc have to implement it again in AF_SMC path. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
D. Wythe authored
Externalize smc proto operations (smc_xxx) to allow access from files other than af_smc.c This is in preparation for the subsequent implementation of the AF_INET version of SMC. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
D. Wythe authored
This patch aims to isolate the shared components of SMC socket allocation by introducing smc_sk_init() for sock initialization and __smc_create_clcsk() for the initialization of clcsock. This is in preparation for the subsequent implementation of the AF_INET version of SMC. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Tested-by: Niklas Schnelle <schnelle@linux.ibm.com> Tested-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
I find the behavior of xa_for_each_start() slightly counter-intuitive. It doesn't end the iteration by making the index point after the last element. IOW calling xa_for_each_start() again after it "finished" will run the body of the loop for the last valid element, instead of doing nothing. This works fine for netlink dumps if they terminate correctly (i.e. coalesce or carefully handle NLM_DONE), but as we keep getting reminded legacy dumps are unlikely to go away. Fixing this generically at the xa_for_each_start() level seems hard - there is no index reserved for "end of iteration". ifindexes are 31b wide, tho, and iterator is ulong so for for_each_netdev_dump() it's safe to go to the next element. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Joe Damato says: ==================== mlx5: Add netdev-genl queue stats Welcome to v5. Switched from RFC to just a v5, because I think this is pretty close. Minor changes from v4 summarized below in the changelog. Note that my NIC does not seem to support PTP and I couldn't get the mlnx-tools mlnx_qos script to work, so I was only able to test the following cases: - device up at boot - adjusting queue counts - device down (e.g. ip link set dev eth4 down) Please see the commit message of patch 2/2 for more details on output and test cases. rfcv4 thread: https://lore.kernel.org/linux-kernel/20240604004629.299699-1-jdamato@fastly.com/T/ rfcv4 -> v5: - Patch 1/2: change variable name 'mlx5e_qid' to 'txq_ix'. - Patch 2/2: - remove logic in mlx5e_get_queue_stats_rx for PTP. PTP RX are always reported in base. - report PTP TX in mlx5e_get_base_stats only if: - PTP has ever been opened, and - either PTP is NULL (closed) or the MLX5E_PTP_STATE_TX bit in its state is not set Otherwise, PTP TX will be reported when the txq_ix is passed into mlx5e_get_queue_stats_tx rfcv3 -> rfcv4: - Patch 1/2 now creates a mapping (priv->txq2sq_stats) which maps txq indices to sq_stats structures so stats can be accessed directly. This mapping is kept up to date along side txq2sq. - Patch 2/2: - All mutex_lock/unlock on state_lock has been dropped. - mlx5e_get_queue_stats_rx now uses ASSERT_RTNL() and has a special case for PTP. If PTP was ever opened, is currently opened, and the channel index matches, stats for PTP RX are output. - mlx5e_get_queue_stats_tx rewritten to use priv->txq2sq_stats. No corner cases are needed here because any txq idx (passed in as i) will have an up to date mapping in priv->txq2sq_stats. - mlx5e_get_base_stats: - in the RX case: - iterates from [params.num_channels, stats_nch) collecting stats. - if ptp was ever opened but is currently closed, add the PTP stats. - in the TX case: - handle 2 cases: - the channel is available, so sum only the unavailable TCs [mlx5e_get_dcb_num_tc, max_opened_tc). - the channel is unavailable, so sum all TCs [0, max_opened_tc). - if ptp was ever opened but is currently closed, add the PTP sq stats. v2 -> rfcv3: - Added patch 1/2 which creates some helpers for computing the txq_ix and ch_ix/tc_ix. - Patch 2/2 modified in several ways: - Fixed variable declarations in mlx5e_get_queue_stats_rx to be at the start of the function. - mlx5e_get_queue_stats_tx rewritten to access sq stats directly by using the helpers added in the previous patch. - mlx5e_get_base_stats modified in several ways: - Took the state_lock when accessing priv->channels. - For the base RX stats, code was simplified to call mlx5e_get_queue_stats_rx instead of repeating the same code. - For the base TX stats, I attempted to implement what I think Tariq suggested in the previous thread: - for available channels, only unavailable TC stats are summed - for unavailable channels, all stats for TCs up to max_opened_tc are summed. v1 - > v2: - Essentially a full rewrite after comments from Jakub, Tariq, and Zhu. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Damato authored
./cli.py --spec netlink/specs/netdev.yaml \ --dump qstats-get --json '{"scope": "queue"}' ...snip {'ifindex': 7, 'queue-id': 62, 'queue-type': 'rx', 'rx-alloc-fail': 0, 'rx-bytes': 105965251, 'rx-packets': 179790}, {'ifindex': 7, 'queue-id': 0, 'queue-type': 'tx', 'tx-bytes': 9402665, 'tx-packets': 17551}, ...snip Also tested with the script tools/testing/selftests/drivers/net/stats.py in several scenarios to ensure stats tallying was correct: - on boot (default queue counts) - adjusting queue count up or down (ethtool -L eth0 combined ...) The tools/testing/selftests/drivers/net/stats.py brings the device up, so to test with the device down, I did the following: $ ip link show eth4 7: eth4: <BROADCAST,MULTICAST> mtu 9000 qdisc mq state DOWN [..snip..] [..snip..] $ cat /proc/net/dev | grep eth4 eth4: 235710489 434811 [..snip rx..] 2878744 21227 [..snip tx..] $ ./cli.py --spec ../../../Documentation/netlink/specs/netdev.yaml \ --dump qstats-get --json '{"ifindex": 7}' [{'ifindex': 7, 'rx-alloc-fail': 0, 'rx-bytes': 235710489, 'rx-packets': 434811, 'tx-bytes': 2878744, 'tx-packets': 21227}] Compare the values in /proc/net/dev match the output of cli for the same device, even while the device is down. Note that while the device is down, per queue stats output nothing (because the device is down there are no queues): $ ./cli.py --spec ../../../Documentation/netlink/specs/netdev.yaml \ --dump qstats-get --json '{"scope": "queue", "ifindex": 7}' [] Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Damato authored
mlx5 currently maps txqs to an sq via priv->txq2sq. It is useful to map txqs to sq_stats, as well, for direct access to stats. Add priv->txq2sq_stats and insert mappings. The mappings will be used next to tabulate stats information. Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 15 Jun, 2024 23 commits
-
-
Sagi Grimberg authored
We only use the mapping in a single context in a short and contained scope, so kmap_local_page is sufficient and cheaper. This will also allow skb_datagram_iter to be called from softirq context. Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Link: https://lore.kernel.org/r/20240613113504.1079860-1-sagi@grimberg.meSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Handle MTU values Amit Cohen writes: The driver uses two values for maximum MTU, but neither is accurate. In addition, the value which is configured to hardware is not calculated correctly. Handle these issues and expose accurate values for minimum and maximum MTU per netdevice. Add test cases to check that the exposed values are really supported. Patch set overview: Patches #1-#3 set the driver to use accurate values for MTU Patch #4 aligns the driver to always use the same value for maximum MTU Patch #5 adds a test ==================== Link: https://lore.kernel.org/r/cover.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
Add cases to check minimum and maximum MTU which are exposed via "ip -d link show". Test configuration and traffic. Use VLAN devices as usually VLAN header (4 bytes) is not included in the MTU, and drivers should configure hardware correctly to send maximum MTU payload size in VLAN tagged packets. $ ./min_max_mtu.sh TEST: ping [ OK ] TEST: ping6 [ OK ] TEST: Test maximum MTU configuration [ OK ] TEST: Test traffic, packet size is maximum MTU [ OK ] TEST: Test minimum MTU configuration [ OK ] TEST: Test traffic, packet size is minimum MTU [ OK ] Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/89de8be8989db7a97f3b39e3c9da695673e78d2e.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
Currently, the driver uses two different values for maximum MTU, one is stored in mlxsw_port->dev->max_mtu and the second is stored in mlxsw_port->max_mtu. The second one is set to value which is queried from firmware. This value was never tested, and unfortunately is not really supported. That means that with the existing code, user can set MTU to X, which is not really supported by firmware and which is bigger than buffer size which is allocated in pci. To make the driver consistent, use only mlxsw_port->dev->max_mtu for maximum MTU value, for buffers headroom add Ethernet frame headers, which are not included in mlxsw_port->dev->max_mtu. Remove mlxsw_port->max_mtu. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/89fa6f804386b918d337e736e14ac291bb947483.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
Currently, the driver uses ETH_MAX_MTU as maximum MTU of netdevices, instead, use the accurate value which is supported by the driver. Subtract Ethernet headers which are taken into account by hardware for MTU checking, as described in the previous patch. Set minimum MTU to ETH_MIN_MTU, as zero MTU is not really supported. With this change: a. The stack will do the MTU checking, so we can remove it from the driver. b. User space will be able to query the actual MTU limits. Before this patch: $ ip -j -d link show dev swp1 | jq | grep mtu "mtu": 1500, "min_mtu": 0, "max_mtu": 65535, With this patch: $ ip -j -d link show dev swp1 | jq | grep mtu "mtu": 1500, "min_mtu": 68, "max_mtu": 10218, Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/be8232e38c196ecb607f82c5e000ea427ce22abb.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
Ethernet frame consists of - Ethernet header, payload, FCS. The MTU value which is used by user is the size of the payload, which means that when user sets MTU to X, the total frame size will be larger due to the addition of the Ethernet header and FCS. Spectrum ASICs take into account Ethernet header and FCS as part of packet size for MTU check. Adjust MTU value when user sets MTU, to configure the MTU size which is required by hardware. The Tx header length which was used by the driver is not relevant for such calculation, take into account Ethernet header (with VLAN extension) and FCS. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/f3203c2477bb8ed18b1e79642fa3e3713e1e55bb.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
Currently mlxsw driver supports up to 10000 bytes for maximum MTU, this value is not accurate, we can support up to 10K bytes. Change the value to the maximum supported MTU by firmware. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/666f51681234aeef09d771833ccb6e94bd323c88.1718275854.git.petrm@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Dan Carpenter authored
Unlike copy_from_user(), put_user() and get_user() return -EFAULT on error. Use the error code directly instead of setting it. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/04a018e8-7433-4f67-8ddd-9357a0114f87@moroto.mountainSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Russell King says: ==================== net: stmmac: provide platform select_pcs method This series adds a select_pcs() method to the stmmac platform data to allow platforms that need to provide their own PCSes to do so, moving the decision making into platform code. This avoids questions such as "what should the priority of XPCS vs some other platform PCS be?" and when we provide a PCS for the internal PCS, how that interacts with both the XPCS and platform provided PCS. Note that if a platform implements the select_pcs() method, then the return values are: - a phylink_pcs pointer - the PCS to be used. - NULL - no phylink_pcs to be used. Otherwise (if not implemented or returns an error-pointer), then allow the the stmmac internal PCS to be used if appropriate (once that patch set is merged.) Patch 1 introduces the new method. Patch 2 converts Intel mGBE to use this to provide the XPCS and removes the XPCS decision making from core code. Patch 3 provides an implementation for rzn1 to return its PCS. Patch 4 does the same for socfpga. Patch 5 removes the core code returning priv->hw->phylink_pcs. No functional change is anticipated. Once this has been merged, it will be expected that platforms should populate all three PCS methods or none of the PCS methods. ==================== Link: https://lore.kernel.org/r/ZmrLbdwv6ALoy+gs@shell.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
Since all platform providers of PCS now populate the select_pcs() method, there is no need for the common code to look at priv->hw->phylink_pcs, so remove it. Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1sHhoh-00FetT-3S@rmk-PC.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
Provide a .select_pcs() implementation which returns the phylink PCS that was created in the .pcs_init() method. Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1sHhob-00FetN-Vp@rmk-PC.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
Provide a .select_pcs() implementation which returns the phylink PCS that was created in the .pcs_init() method. Tested-by: Romain Gantois <romain.gantois@bootlin.com> Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1sHhoW-00FetH-GD@rmk-PC.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
Move the code returning the XPCS into dwmac-intel, which is the only user of XPCS. Fill in the select_pcs() implementation only when we are going to setup the XPCS, thus when it should be present. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1sHhoR-00FetB-CP@rmk-PC.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
Allow platform drivers to provide their logic to select an appropriate PCS. Tested-by: Romain Gantois <romain.gantois@bootlin.com> Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1sHhoM-00Fesu-8E@rmk-PC.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Tariq Toukan says: ==================== mlx5 misc patches 2023-06-13 This patchset contains small code cleanups and enhancements from the team to the mlx5 core and Eth drivers. Series generated against: commit 3ec8d757 ("CDC-NCM: add support for Apple's private interface") ==================== Link: https://lore.kernel.org/r/20240613210036.1125203-1-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Rahul Rameshbabu authored
Calculate the pseudo-header checksum for both IPSec transport mode and IPSec tunnel mode for mlx5 devices that do not implement a pure hardware checksum offload for L4 checksum calculation. Introduce a capability bit that identifies such mlx5 devices. Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-7-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Gal Pressman authored
Use the tcp specific helpers to calculate the tcp pseudo header checksum instead of the csum_*_magic ones. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-6-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Gal Pressman authored
The code no longer treats only UDP tunnels, adjust the outdated comment. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-5-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Moshe Shemesh authored
Replace deprecated strcpy with strscpy. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-4-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Chris Mi authored
Currently a ct entry is stored in both ct and ct-nat tables. ct action is directed to the ct table, while ct nat action is directed to the nat table. ct-nat entries perform the nat header rewrites, if required. The current design assures that a ct action will match in hardware even if the tuple has nat configured, it will just not execute it. However, storing each connection in two tables increases the system's memory consumption while reducing its insertion rate. Offload a connection to either ct or the ct-nat table. Add a miss fall-through rule from ct-nat table to the ct table allowing ct(nat) action on non-natted connections. ct action on natted connections, by default, will be handled by the software miss path. Signed-off-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Chris Mi <cmi@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-3-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Cosmin Ratiu authored
TSAR is the correct spelling (Transmit Scheduling ARbiter). Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-2-tariqt@nvidia.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Chris Packham authored
The Realtek RTL8224 PHY is a 2.5Gbps capable PHY. It only uses the clause 45 MDIO interface and can leverage the support that has already been added for the other 822x PHYs. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20240611053415.2111723-1-chris.packham@alliedtelesis.co.nzSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Commit 12c2d0a5 ("net: lan966x: add ethtool configuration and statistics") added support for various standard stats. We should not clear the stats which are not collected by the device. Core code uses a special initializer to detect when device does not report given stat. Acked-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20240613003222.3327368-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 14 Jun, 2024 10 commits
-
-
Chris Lew authored
Ignore the ENODEV failures returned by kernel_sendmsg(). These errors indicate that either the local port has been closed or the remote has gone down. Neither of these scenarios are fatal and will eventually be handled through packets that are later queued on the control port. Signed-off-by: Chris Lew <quic_clew@quicinc.com> Signed-off-by: Sarannya Sasikumar <quic_sarannya@quicinc.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240612063156.1377210-1-quic_sarannya@quicinc.comSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Christophe Roullier says: ==================== Series to deliver Ethernet for STM32MP13 STM32MP13 is STM32 SOC with 2 GMACs instances GMAC IP version is SNPS 4.20. GMAC IP configure with 1 RX and 1 TX queue. DMA HW capability register supported RX Checksum Offload Engine supported TX Checksum insertion supported Wake-Up On Lan supported TSO supported Rework dwmac glue to simplify management for next stm32 (integrate RFC from Marek) V2: - Remark from Rob Herring (add Krzysztof's ack in patch 02/11, update in yaml) Remark from Serge Semin (upate commits msg) V3: - Remove PHY regulator patch and Ethernet2 DT because need to clarify how to manage PHY regulator (in glue or PHY side) - Integrate RFC from Marek - Remark from Rob Herring in YAML documentation V4: - Remark from Marek (remove max-speed, extra space in DT, update commit msg) - Remark from Rasmus (add sign-off, add base-commit) - Remark from Sai Krishna Gajula V5: - Fix warning during build CHECK_DTBS - Remark from Marek (glue + DT update) - Remark from Krzysztof about YAML (Make it symmetric) V6: - Replace pr_debug by dev_dbg - Split serie driver/DTs separately V7: - Remark from Marek (update sysconfig register mask) ==================== Link: https://lore.kernel.org/r/20240611083606.733453-1-christophe.roullier@foss.st.comSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
Christophe Roullier authored
Add Ethernet support for STM32MP13. STM32MP13 is STM32 SOC with 2 GMACs instances. GMAC IP version is SNPS 4.20. GMAC IP configure with 1 RX and 1 TX queue. DMA HW capability register supported RX Checksum Offload Engine supported TX Checksum insertion supported Wake-Up On Lan supported TSO supported Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Christophe Roullier authored
Add possibility to have second argument in syscon property to manage mask. This mask will be used to address right BITFIELDS of PMCR register. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Marek Vasut authored
Trivial, fix up the comments using 'Mhz' to 'MHz'. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Marek Vasut authored
Use dev_err()/dev_dbg() and phy_modes() to print PHY mode instead of pr_debug() and hand-written PHY mode decoding. This way, each debug print has associated device with it and duplicated mode decoding is removed. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Marek Vasut authored
Pull the PMCR clock mux configuration into a separate function. This is the final change of three, which moves external clock rate validation, external clock selector decoding, and clock mux configuration into separate functions. This should make the code easier to understand. No functional change intended. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Marek Vasut authored
Pull the external clock selector into a separate function, to avoid conflating it with external clock rate validation and clock mux register configuration. This should make the code easier to read and understand. The dwmac->enable_eth_ck variable in the end indicates whether the MAC clock are supplied by external oscillator (true) or internal RCC clock IP (false). The dwmac->enable_eth_ck value is set based on multiple DT properties, some of them deprecated, some of them specific to bus mode. The following DT properties and variables are taken into account. In each case, if the property is present or true, MAC clock is supplied by external oscillator. - "st,ext-phyclk", assigned to variable dwmac->ext_phyclk - Used in any mode (MII/RMII/GMII/RGMII) - The only non-deprecated DT property of the three - "st,eth-clk-sel", assigned to variable dwmac->eth_clk_sel_reg - Valid only in GMII/RGMII mode - Deprecated property, backward compatibility only - "st,eth-ref-clk-sel", assigned to variable dwmac->eth_ref_clk_sel_reg - Valid only in RMII mode - Deprecated property, backward compatibility only The stm32mp1_select_ethck_external() function handles the aforementioned DT properties and sets dwmac->enable_eth_ck accordingly. The stm32mp1_set_mode() is adjusted to call stm32mp1_select_ethck_external() first and then only use dwmac->enable_eth_ck to determine hardware clock mux settings. No functional change intended. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Marek Vasut authored
Pull the external clock frequency validation into a separate function, to avoid conflating it with external clock DT property decoding and clock mux register configuration. This should make the code easier to read and understand. This does change the code behavior slightly. The clock mux PMCR register setting now depends solely on the DT properties which configure the clock mux between external clock and internal RCC generated clock. The mux PMCR register settings no longer depend on the supplied clock frequency, that supplied clock frequency is now only validated, and if the clock frequency is invalid for a mode, it is rejected. Previously, the code would switch the PMCR register clock mux to internal RCC generated clock if external clock couldn't provide suitable frequency, without checking whether the RCC generated clock frequency is correct. Such behavior is risky at best, user should have configured their clock correctly in the first place, so this behavior is removed here. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
Christophe Roullier authored
New STM32 SOC have 2 GMACs instances. GMAC IP version is SNPS 4.20. Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-