kernel/linux.git/drivers/net/ethernet/faraday, branch v6.6.150

net: ftgmac100: fix ring allocation unwind on open failure

2026-04-11T12:19:32+00:00

commit c0fd0fe745f5e8c568d898cd1513d0083e46204a upstream. ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style. Fixes: d72e01a0430f ("ftgmac100: Use a scratch buffer for failed RX allocations") Cc: stable@vger.kernel.org Signed-off-by: Yufan Chen Link: https://patch.msgid.link/20260328163257.60836-1-yufan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: ftgmac100: select FIXED_PHY

2025-06-27T10:08:48+00:00

commit ae409629e022fbebbc6d31a1bfeccdbbeee20fd6 upstream. Depending on e.g. DT configuration this driver uses a fixed link. So we shouldn't rely on the user to enable FIXED_PHY, select it in Kconfig instead. We may end up with a non-functional driver otherwise. Fixes: 38561ded50d0 ("net: ftgmac100: support fixed link") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Link: https://patch.msgid.link/476bb33b-5584-40f0-826a-7294980f2895@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: ftgmac100: Ensure tx descriptor updates are visible

2024-09-30T14:25:09+00:00

[ Upstream commit 4186c8d9e6af57bab0687b299df10ebd47534a0a ] The driver must ensure TX descriptor updates are visible before updating TX pointer and TX clear pointer. This resolves TX hangs observed on AST2600 when running iperf3. Signed-off-by: Jacky Chou Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: ftgmac100: Enable TX interrupt to avoid TX timeout

2024-09-18T17:24:09+00:00

[ Upstream commit fef2843bb49f414d1523ca007d088071dee0e055 ] Currently, the driver only enables RX interrupt to handle RX packets and TX resources. Sometimes there is not RX traffic, so the TX resource needs to wait for RX interrupt to free. This situation will toggle the TX timeout watchdog when the MAC TX ring has no more resources to transmit packets. Therefore, enable TX interrupt to release TX resources at any time. When I am verifying iperf3 over UDP, the network hangs. Like the log below. root# iperf3 -c 192.168.100.100 -i1 -t10 -u -b0 Connecting to host 192.168.100.100, port 5201 [ 4] local 192.168.100.101 port 35773 connected to 192.168.100.100 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-20.42 sec 160 KBytes 64.2 Kbits/sec 20 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-20.42 sec 160 KBytes 64.2 Kbits/sec 0.000 ms 0/20 (0%) [ 4] Sent 20 datagrams iperf3: error - the server has terminated The network topology is FTGMAC connects directly to a PC. UDP does not need to wait for ACK, unlike TCP. Therefore, FTGMAC needs to enable TX interrupt to release TX resources instead of waiting for the RX interrupt. Fixes: 10cbd6407609 ("ftgmac100: Rework NAPI & interrupts handling") Signed-off-by: Jacky Chou Link: https://patch.msgid.link/20240906062831.2243399-1-jacky_chou@aspeedtech.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: ftmac100: add multicast filtering possibility

2023-08-11T05:58:31+00:00

If netdev_mc_count() is not zero and not IFF_ALLMULTI, filter incoming multicast packets. The chip has a Multicast Address Hash Table for allowed multicast addresses, so we fill it. Implement .ndo_set_rx_mode and recalculate multicast hash table. Also observe change of IFF_PROMISC and IFF_ALLMULTI netdev flags. Signed-off-by: Sergei Antonov Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller

net: ftgmac100: support getting MAC address from NVMEM

2023-07-18T07:15:40+00:00

Make use of of_get_ethdev_address() to support reading MAC address not only from the usual DT nodes but also from an NVMEM provider (e.g. using a dedicated area in an FRU EEPROM). Signed-off-by: Paul Fertser Link: https://lore.kernel.org/r/20230713095743.30517-1-fercerpav@gmail.com Signed-off-by: Paolo Abeni

net: ftmac100: handle netdev flags IFF_PROMISC and IFF_ALLMULTI

2023-01-18T13:03:40+00:00

When netdev->flags has IFF_PROMISC or IFF_ALLMULTI, set the corresponding bits in the MAC Control Register (MACCR). This change is based on code from the ftgmac100 driver, see ftgmac100_start_hw() in ftgmac100.c Signed-off-by: Sergei Antonov Signed-off-by: David S. Miller

net: ftmac100: allow increasing MTU to make most use of single-segment buffers

2022-11-01T03:02:57+00:00

If the FTMAC100 is used as a DSA master, then it is expected that frames which are MTU sized on the wire facing the external switch port (1500 octets in L2 payload, plus L2 header) also get a DSA tag when seen by the host port. This extra tag increases the length of the packet as the host port sees it, and the FTMAC100 is not prepared to handle frames whose length exceeds 1518 octets (including FCS) at all. Only a minimal rework is needed to support this configuration. Since MTU-sized DSA-tagged frames still fit within a single buffer (RX_BUF_SIZE), we just need to optimize the resource management rather than implement multi buffer RX. In ndo_change_mtu(), we toggle the FTMAC100_MACCR_RX_FTL bit to tell the hardware to drop (or not) frames with an L2 payload length larger than 1500. We need to replicate the MACCR configuration in ftmac100_start_hw() as well, since there is a hardware reset there which clears previous settings. The advantage of dynamically changing FTMAC100_MACCR_RX_FTL is that when dev->mtu is at the default value of 1500, large frames are automatically dropped in hardware and we do not spend CPU cycles dropping them. Suggested-by: Vladimir Oltean Signed-off-by: Sergei Antonov Link: https://lore.kernel.org/r/20221028183220.155948-3-saproj@gmail.com Signed-off-by: Jakub Kicinski

net: ftmac100: report the correct maximum MTU of 1500

2022-11-01T03:02:57+00:00

The driver uses the MAX_PKT_SIZE (1518) for both MTU reporting and for TX. However, the 2 places do not measure the same thing. On TX, skb->len measures the entire L2 packet length (without FCS, which software does not possess). So the comparison against 1518 there is correct. What is not correct is the reporting of dev->max_mtu as 1518. Since MTU measures L2 *payload* length (excluding L2 overhead) and not total L2 packet length, it means that the correct max_mtu supported by this device is the standard 1500. Anything higher than that will be dropped on RX currently. To fix this, subtract VLAN_ETH_HLEN from MAX_PKT_SIZE when reporting the max_mtu, since that is the difference between L2 payload length and total L2 length as seen by software. Signed-off-by: Vladimir Oltean Signed-off-by: Sergei Antonov Link: https://lore.kernel.org/r/20221028183220.155948-2-saproj@gmail.com Signed-off-by: Jakub Kicinski

net: ftmac100: prepare data path for receiving single segment packets > 1514

2022-11-01T03:02:57+00:00

Eliminate one check in the data path and move it elsewhere, to where our real limitation is. We'll want to start processing "too long" frames in the driver (currently there is a hardware MAC setting which drops theses). Signed-off-by: Vladimir Oltean Signed-off-by: Sergei Antonov Link: https://lore.kernel.org/r/20221028183220.155948-1-saproj@gmail.com Signed-off-by: Jakub Kicinski