delta/linux.git/drivers/net/ethernet/faraday, branch master

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

net: drop the weight argument from netif_napi_add

2022-09-29T01:57:14+00:00

We tell driver developers to always pass NAPI_POLL_WEIGHT
as the weight to netif_napi_add(). This may be confusing
to newcomers, drop the weight argument, those who really
need to tweak the weight can use netif_napi_add_weight().

Acked-by: Marc Kleine-Budde  # for CAN
Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski

net: ftgmac100: support fixed link

2022-09-15T10:41:37+00:00

Support fixed link in ftgmac100 driver. Fixed link is used on several
Meta OpenBMC platforms, such as Elbert (AST2620) and Wedge400 (AST2520).

Signed-off-by: Tao Ren 
Reviewed-by: Andrew Lunn 
Reviewed-by: Florian Fainelli 
Signed-off-by: Paolo Abeni

net: ftmac100: fix endianness-related issues from 'sparse'

2022-09-06T08:24:05+00:00

Sparse found a number of endianness-related issues of these kinds:

.../ftmac100.c:192:32: warning: restricted __le32 degrades to integer

.../ftmac100.c:208:23: warning: incorrect type in assignment (different base types)
.../ftmac100.c:208:23:    expected unsigned int rxdes0
.../ftmac100.c:208:23:    got restricted __le32 [usertype]

.../ftmac100.c:249:23: warning: invalid assignment: &=
.../ftmac100.c:249:23:    left side has type unsigned int
.../ftmac100.c:249:23:    right side has type restricted __le32

.../ftmac100.c:527:16: warning: cast to restricted __le32

Change type of some fields from 'unsigned int' to '__le32' to fix it.

Signed-off-by: Sergei Antonov 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20220902113749.1408562-1-saproj@gmail.com
Signed-off-by: Paolo Abeni

net: ethernet: move from strlcpy with unused retval to strscpy

2022-08-31T21:11:26+00:00

Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang 
Reviewed-by: Petr Machata  # For drivers/net/ethernet/mellanox/mlxsw
Acked-by: Geoff Levand  # For ps3_gelic_net and spider_net_ethtool
Acked-by: Tom Lendacky  # For drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c
Acked-by: Marcin Wojtas  # For drivers/net/ethernet/marvell/mvpp2
Reviewed-by: Leon Romanovsky  # For drivers/net/ethernet/mellanox/mlx{4|5}
Reviewed-by: Shay Agroskin  # For drivers/net/ethernet/amazon/ena
Acked-by: Krzysztof Hałasa  # For IXP4xx Ethernet
Link: https://lore.kernel.org/r/20220830201457.7984-3-wsa+renesas@sang-engineering.com
Signed-off-by: Jakub Kicinski

net: ftmac100: add an opportunity to get ethaddr from the platform

2022-08-27T02:26:11+00:00

This driver always generated a random ethernet address. Leave it as a
fallback solution, but add a call to platform_get_ethdev_address().
Handle EPROBE_DEFER returned from platform_get_ethdev_address() to
retry when EEPROM is ready.

Signed-off-by: Sergei Antonov 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20220824151724.2698107-1-saproj@gmail.com
Signed-off-by: Jakub Kicinski

net: ftmac100: set max_mtu to allow DSA overhead setting

2022-08-23T22:30:58+00:00

In case ftmac100 is used with a DSA switch, Linux wants to set MTU
to 1504 to accommodate for DSA overhead. With the default max_mtu
it leads to the error message:
 ftmac100 92000000.mac eth0: error -22 setting MTU to 1504 to include DSA overhead

ftmac100 supports packet length 1518 (MAX_PKT_SIZE constant), so it is
safe to report it in max_mtu.

Signed-off-by: Sergei Antonov 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20220821160844.474277-1-saproj@gmail.com
Signed-off-by: Jakub Kicinski