Eric Dumazet [Tue, 13 Feb 2024 06:32:42 +0000 (06:32 +0000)]
net: add netdev_set_operstate() helper
dev_base_lock is going away, add netdev_set_operstate() helper
so that hsr does not have to know core internals.
Remove dev_base_lock acquisition from rfc2863_policy()
v3: use an "unsigned int" for dev->operstate,
so that try_cmpxchg() can work on all arches.
( https://lore.kernel.org/oe-kbuild-all/202402081918.OLyGaea3-lkp@intel.com/ )
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 14 Feb 2024 11:01:01 +0000 (11:01 +0000)]
Merge branch 'per-epoll-context-busy-poll'
Joe Damato says:
====================
Per epoll context busy poll support
Greetings:
Welcome to v8.
TL;DR This builds on commit bf3b9f6372c4 ("epoll: Add busy poll support to
epoll with socket fds.") by allowing user applications to enable
epoll-based busy polling, set a busy poll packet budget, and enable or
disable prefer busy poll on a per epoll context basis.
This makes epoll-based busy polling much more usable for user
applications than the current system-wide sysctl and hardcoded budget.
To allow for this, two ioctls have been added for epoll contexts for
getting and setting a new struct, struct epoll_params.
ioctl was chosen vs a new syscall after reviewing a suggestion by Willem
de Bruijn [1]. I am open to using a new syscall instead of an ioctl, but it
seemed that:
- Busy poll affects all existing epoll_wait and epoll_pwait variants in
the same way, so new verions of many syscalls might be needed. It
seems much simpler for users to use the correct
epoll_wait/epoll_pwait for their app and add a call to ioctl to enable
or disable busy poll as needed. This also probably means less work to
get an existing epoll app using busy poll.
- previously added epoll_pwait2 helped to bring epoll closer to
existing syscalls (like pselect and ppoll) and this busy poll change
reflected as a new syscall would not have the same effect.
Note: patch 1/4 as of v4 uses an or (||) instead of an xor. I thought about
it some more and I realized that if the user enables both the per-epoll
context setting and the system wide sysctl, then busy poll should be
enabled and not disabled. Using xor doesn't seem to make much sense after
thinking through this a bit.
Longer explanation:
Presently epoll has support for a very useful form of busy poll based on
the incoming NAPI ID (see also: SO_INCOMING_NAPI_ID [2]).
This form of busy poll allows epoll_wait to drive NAPI packet processing
which allows for a few interesting user application designs which can
reduce latency and also potentially improve L2/L3 cache hit rates by
deferring NAPI until userland has finished its work.
The documentation available on this is, IMHO, a bit confusing so please
allow me to explain how one might use this:
1. Ensure each application thread has its own epoll instance mapping
1-to-1 with NIC RX queues. An n-tuple filter would likely be used to
direct connections with specific dest ports to these queues.
2. Optionally: Setup IRQ coalescing for the NIC RX queues where busy
polling will occur. This can help avoid the userland app from being
pre-empted by a hard IRQ while userland is running. Note this means that
userland must take care to call epoll_wait and not take too long in
userland since it now drives NAPI via epoll_wait.
3. Optionally: Consider using napi_defer_hard_irqs and gro_flush_timeout to
further restrict IRQ generation from the NIC. These settings are
system-wide so their impact must be carefully weighed against the running
applications.
4. Ensure that all incoming connections added to an epoll instance
have the same NAPI ID. This can be done with a BPF filter when
SO_REUSEPORT is used or getsockopt + SO_INCOMING_NAPI_ID when a single
accept thread is used which dispatches incoming connections to threads.
5. Lastly, busy poll must be enabled via a sysctl
(/proc/sys/net/core/busy_poll).
Please see Eric Dumazet's paper about busy polling [3] and a recent
academic paper about measured performance improvements of busy polling [4]
(albeit with a modification that is not currently present in the kernel)
for additional context.
The unfortunate part about step 5 above is that this enables busy poll
system-wide which affects all user applications on the system,
including epoll-based network applications which were not intended to
be used this way or applications where increased CPU usage for lower
latency network processing is unnecessary or not desirable.
If the user wants to run one low latency epoll-based server application
with epoll-based busy poll, but would like to run the rest of the
applications on the system (which may also use epoll) without busy poll,
this system-wide sysctl presents a significant problem.
This change preserves the system-wide sysctl, but adds a mechanism (via
ioctl) to enable or disable busy poll for epoll contexts as needed by
individual applications, making epoll-based busy poll more usable.
Note that this change includes an or (as of v4) instead of an xor. If the
user has enabled both the system-wide sysctl and also the per epoll-context
busy poll settings, then epoll should probably busy poll (vs being
disabled).
Thanks,
Joe
v7 -> v8:
- Reviewed-by tag from Eric Dumazet applied to commit message of patch
1/4.
- patch 4/4:
- EPIOCSPARAMS and EPIOCGPARAMS updated to use WRITE_ONCE and
READ_ONCE, as requested by Eric Dumazet
- Wrapped a long line (via netdev/checkpatch)
v6 -> v7:
- Acked-by tags from Stanislav Fomichev applied to commit messages of
all patches.
- Reviewed-by tags from Jakub Kicinski, Eric Dumazet applied to commit
messages of patches 2 and 3. Jiri Slaby's Reviewed-by applied to patch
4.
- patch 1/4:
- busy_poll_usecs reduced from u64 to u32.
- Unnecessary parens removed (via netdev/checkpatch)
- Wrapped long line (via netdev/checkpatch)
- Remove inline from busy_loop_ep_timeout as objdump suggests the
function is already inlined
- Moved struct eventpoll assignment to declaration
- busy_loop_ep_timeout is moved within CONFIG_NET_RX_BUSY_POLL and the
ifdefs internally have been removed as per Eric Dumazet's review
- Removed ep_busy_loop_on from the !defined CONFIG_NET_RX_BUSY_POLL
section as it is only called when CONFIG_NET_RX_BUSY_POLL is
defined
- patch 4/4:
- epoll_params.busy_poll_usecs has been reduced to u32
- epoll_params.busy_poll_usecs is now checked to ensure it is <=
S32_MAX
- __pad has been reduced to a single u8
- memchr_inv has been dropped and replaced with a simple check for the
single __pad byte
- Removed space after cast (via netdev/checkpatch)
- Wrap long line (via netdev/checkpatch)
- Move struct eventpoll *ep assignment to declaration as per Jiri
Slaby's review
- Remove unnecessary !! as per Jiri Slaby's review
- Reorganized variables to be reverse christmas tree order
v5 -> v6:
- patch 1/3 no functional change, but commit message corrected to explain
that an or (||) is being used instead of xor.
- patch 3/4 is a new patch which adds support for per epoll context
prefer busy poll setting.
- patch 4/4 updated to allow getting/setting per epoll context prefer
busy poll setting; this setting is limited to either 0 or 1.
v4 -> v5:
- patch 3/3 updated to use memchr_inv to ensure that __pad is zero for
the EPIOCSPARAMS ioctl. Recommended by Greg K-H [5], Dave Chinner [6],
and Jiri Slaby [7].
v3 -> v4:
- patch 1/3 was updated to include an important functional change:
ep_busy_loop_on was updated to use or (||) instead of xor (^). After
thinking about it a bit more, I thought xor didn't make much sense.
Enabling both the per-epoll context and the system-wide sysctl should
probably enable busy poll, not disable it. So, or (||) makes more
sense, I think.
- patch 3/3 was updated:
- to change the epoll_params fields to be __u64, __u16, and __u8 and
to pad the struct to a multiple of 64bits. Suggested by Greg K-H [8]
and Arnd Bergmann [9].
- remove an unused pr_fmt, left over from the previous revision.
- ioctl now returns -EINVAL when epoll_params.busy_poll_usecs >
U32_MAX.
v2 -> v3:
- cover letter updated to mention why ioctl seems (to me) like a better
choice vs a new syscall.
- patch 3/4 was modified in 3 ways:
- when an unknown ioctl is received, -ENOIOCTLCMD is returned instead
of -EINVAL as the ioctl documentation requires.
- epoll_params.busy_poll_budget can only be set to a value larger than
NAPI_POLL_WEIGHT if code is run by privileged (CAP_NET_ADMIN) users.
Otherwise, -EPERM is returned.
- busy poll specific ioctl code moved out to its own function. On
kernels without busy poll support, -EOPNOTSUPP is returned. This also
makes the kernel build robot happier without littering the code with
more #ifdefs.
- dropped patch 4/4 after Eric Dumazet's review of it when it was sent
independently to the list [10].
v1 -> v2:
- cover letter updated to make a mention of napi_defer_hard_irqs and
gro_flush_timeout as an added step 3 and to cite both Eric Dumazet's
busy polling paper and a paper from University of Waterloo for
additional context. Specifically calling out the xor in patch 1/4
incase it is missed by reviewers.
- Patch 2/4 has its commit message updated, but no functional changes.
Commit message now describes that allowing for a settable budget helps
to improve throughput and is more consistent with other busy poll
mechanisms that allow a settable budget via SO_BUSY_POLL_BUDGET.
- Patch 3/4 was modified to check if the epoll_params.busy_poll_budget
exceeds NAPI_POLL_WEIGHT. The larger value is allowed, but an error is
printed. This was done for consistency with netif_napi_add_weight,
which does the same.
- Patch 3/4 the struct epoll_params was updated to fix the type of the
data field; it was uint8_t and was changed to u8.
- Patch 4/4 added to check if SO_BUSY_POLL_BUDGET exceeds
NAPI_POLL_WEIGHT. The larger value is allowed, but an error is
printed. This was done for consistency with netif_napi_add_weight,
which does the same.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Damato [Tue, 13 Feb 2024 06:16:45 +0000 (06:16 +0000)]
eventpoll: Add epoll ioctl for epoll_params
Add an ioctl for getting and setting epoll_params. User programs can use
this ioctl to get and set the busy poll usec time, packet budget, and
prefer busy poll params for a specific epoll context.
Parameters are limited:
- busy_poll_usecs is limited to <= s32_max
- busy_poll_budget is limited to <= NAPI_POLL_WEIGHT by unprivileged
users (!capable(CAP_NET_ADMIN))
- prefer_busy_poll must be 0 or 1
- __pad must be 0
Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Damato [Tue, 13 Feb 2024 06:16:44 +0000 (06:16 +0000)]
eventpoll: Add per-epoll prefer busy poll option
When using epoll-based busy poll, the prefer_busy_poll option is hardcoded
to false. Users may want to enable prefer_busy_poll to be used in
conjunction with gro_flush_timeout and defer_hard_irqs_count to keep device
IRQs masked.
Other busy poll methods allow enabling or disabling prefer busy poll via
SO_PREFER_BUSY_POLL, but epoll-based busy polling uses a hardcoded value.
Fix this edge case by adding support for a per-epoll context
prefer_busy_poll option. The default is false, as it was hardcoded before
this change.
Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Damato [Tue, 13 Feb 2024 06:16:43 +0000 (06:16 +0000)]
eventpoll: Add per-epoll busy poll packet budget
When using epoll-based busy poll, the packet budget is hardcoded to
BUSY_POLL_BUDGET (8). Users may desire larger busy poll budgets, which
can potentially increase throughput when busy polling under high network
load.
Other busy poll methods allow setting the busy poll budget via
SO_BUSY_POLL_BUDGET, but epoll-based busy polling uses a hardcoded
value.
Fix this edge case by adding support for a per-epoll context busy poll
packet budget. If not specified, the default value (BUSY_POLL_BUDGET) is
used.
Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Damato [Tue, 13 Feb 2024 06:16:42 +0000 (06:16 +0000)]
eventpoll: support busy poll per epoll instance
Allow busy polling on a per-epoll context basis. The per-epoll context
usec timeout value is preferred, but the pre-existing system wide sysctl
value is still supported if it specified.
busy_poll_usecs is a u32, but in a follow up patch the ioctl provided to
the user only allows setting a value from 0 to S32_MAX.
Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Kamal Heib [Tue, 13 Feb 2024 03:17:18 +0000 (22:17 -0500)]
net: ena: Remove redundant assignment
There is no point in initializing an ndo to NULL, therefore the
assignment is redundant and can be removed.
Signed-off-by: Kamal Heib <kheib@redhat.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Acked-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Hariprasad Kelam [Mon, 12 Feb 2024 13:15:23 +0000 (18:45 +0530)]
Octeontx2-af: Fetch MAC channel info from firmware
Packet ingress and egress MAC/serdes channel numbers are configurable
on CN10K series of silicons. These channel numbers inturn used while
installing MCAM rules to match ingress/egress port. Fetch these channel
numbers from firmware at driver init time.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
this is a pull request of 23 patches for net-next/master.
The first patch is by Nicolas Maier and targets the CAN Broadcast
Manager (bcm), it adds message flags to distinguish between own local
and remote traffic.
Oliver Hartkopp contributes a patch for the CAN ISOTP protocol that
adds dynamic flow control parameters.
Stefan Mätje's patch series add support for the esd PCIe/402 CAN
interface family.
Markus Schneider-Pargmann contributes 14 patches for the m_can to
optimize for the SPI attached tcan4x5x controller.
A patch by Vincent Mailhol replaces Wolfgang Grandegger by Vincent
Mailhol as the CAN drivers Co-Maintainer.
Jimmy Assarsson's patch add support for the Kvaser M.2 PCIe 4xCAN
adapter.
A patch by Daniil Dulov removed a redundant NULL check in the softing
driver.
Oliver Hartkopp contributes a patch to add CANXL virtual CAN network
identifier support.
A patch by myself removes Naga Sureshkumar Relli as the maintainer of
the xilinx_can driver, as their email bounces.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
====================
add multi-buff support for xdp running in generic mode
Introduce multi-buffer support for xdp running in generic mode not always
linearizing the skb in netif_receive_generic_xdp routine.
Introduce generic percpu page_pools allocator.
====================
Lorenzo Bianconi [Mon, 12 Feb 2024 09:50:56 +0000 (10:50 +0100)]
xdp: add multi-buff support for xdp running in generic mode
Similar to native xdp, do not always linearize the skb in
netif_receive_generic_xdp routine but create a non-linear xdp_buff to be
processed by the eBPF program. This allow to add multi-buffer support
for xdp running in generic mode.
Lorenzo Bianconi [Mon, 12 Feb 2024 09:50:55 +0000 (10:50 +0100)]
xdp: rely on skb pointer reference in do_xdp_generic and netif_receive_generic_xdp
Rely on skb pointer reference instead of the skb pointer in do_xdp_generic
and netif_receive_generic_xdp routine signatures.
This is a preliminary patch to add multi-buff support for xdp running in
generic mode where we will need to reallocate the skb to avoid
linearization and we will need to make it visible to do_xdp_generic()
caller.
Lorenzo Bianconi [Mon, 12 Feb 2024 09:50:54 +0000 (10:50 +0100)]
net: add generic percpu page_pool allocator
Introduce generic percpu page_pools allocator.
Moreover add page_pool_create_percpu() and cpuid filed in page_pool struct
in order to recycle the page in the page_pool "hot" cache if
napi_pp_put_page() is running on the same cpu.
This is a preliminary patch to add xdp multi-buff support for xdp running
in generic mode.
Luiz Angelo Daros de Luca [Mon, 12 Feb 2024 21:34:33 +0000 (18:34 -0300)]
net: dsa: realtek: fix digital interface select macro for EXT0
While no supported devices currently utilize EXT0, the register reserves
the bits for an EXT0. EXT0 is utilized by devices from the generation
prior to rtl8365mb, such as those supported by the driver library
rtl8367b.
Heiner Kallweit [Mon, 12 Feb 2024 18:57:46 +0000 (19:57 +0100)]
r8169: add generic rtl_set_eee_txidle_timer function
Add a generic setter for the EEE tx idle timer and use it with all
RTL8125/RTL8126 chip versions, in line with the vendor driver.
This prepares for adding EEE tx idle timer support for additional
chip versions.
Eric Dumazet [Sun, 11 Feb 2024 21:44:03 +0000 (21:44 +0000)]
vlan: use xarray iterator to implement /proc/net/vlan/config
Adopt net->dev_by_index as I did in commit 0e0939c0adf9
("net-procfs: use xarray iterator to implement /proc/net/dev")
Not only this removes quadratic behavior, it also makes sure
an existing vlan device is always visible in the dump,
regardless of concurrent net->dev_base_head changes.
Robert Marko [Sun, 11 Feb 2024 18:16:41 +0000 (19:16 +0100)]
net: phy: aquantia: clear PMD Global Transmit Disable bit during init
PMD Global Transmit Disable bit should be cleared for normal operation.
This should be HW default, however I found that on Asus RT-AX89X that uses
AQR113C PHY and firmware 5.4 this bit is set by default.
With this bit set the AQR cannot achieve a link with its link-partner and
it took me multiple hours of digging through the vendor GPL source to find
this out, so lets always clear this bit during .config_init() to avoid a
situation like this in the future.
Stephen Hemminger [Sun, 11 Feb 2024 17:24:55 +0000 (09:24 -0800)]
net: sched: codel replace GPLv2/BSD boilerplate
The prologue to codel is using BSD-3 clause and GPL-2 boiler plate
language. Replace it by using SPDX. The automated treewide scan in
commit d2912cb15bdd ("treewide: Replace GPLv2 boilerplate/reference with
SPDX - rule 500") did not pickup dual licensed code.
Oliver Hartkopp [Mon, 12 Feb 2024 21:35:50 +0000 (22:35 +0100)]
can: canxl: add virtual CAN network identifier support
CAN XL data frames contain an 8-bit virtual CAN network identifier (VCID).
A VCID value of zero represents an 'untagged' CAN XL frame.
To receive and send these optional VCIDs via CAN_RAW sockets a new socket
option CAN_RAW_XL_VCID_OPTS is introduced to define/access VCID content:
- tx: set the outgoing VCID value by the kernel (one fixed 8-bit value)
- tx: pass through VCID values from the user space (e.g. for traffic replay)
- rx: apply VCID receive filter (value/mask) to be passed to the user space
With the 'tx pass through' option CAN_RAW_XL_VCID_TX_PASS all valid VCID
values can be sent, e.g. to replay full qualified CAN XL traffic.
The VCID value provided for the CAN_RAW_XL_VCID_TX_SET option will
override the VCID value in the struct canxl_frame.prio defined for
CAN_RAW_XL_VCID_TX_PASS when both flags are set.
With a rx_vcid_mask of zero all possible VCID values (0x00 - 0xFF) are
passed to the user space when the CAN_RAW_XL_VCID_RX_FILTER flag is set.
Without this flag only untagged CAN XL frames (VCID = 0x00) are delivered
to the user space (default).
The 8-bit VCID is stored inside the CAN XL prio element (only in CAN XL
frames!) to not interfere with other CAN content or the CAN filters
provided by the CAN_RAW sockets and kernel infrastruture.
Kurt Kanzenbach [Thu, 8 Feb 2024 10:35:25 +0000 (11:35 +0100)]
net: stmmac: Simplify mtl IRQ status checking
Commit 8a7cb245cf28 ("net: stmmac: Do not enable RX FIFO overflow
interrupts") disabled the RX FIFO overflow interrupts. However, it left the
status variable around, but never checks it.
As stmmac_host_mtl_irq_status() returns only 0 now, the code can be
simplified.
Guillaume Nault [Fri, 9 Feb 2024 16:43:37 +0000 (17:43 +0100)]
ipv4: Set the routing scope properly in ip_route_output_ports().
Set scope automatically in ip_route_output_ports() (using the socket
SOCK_LOCALROUTE flag). This way, callers don't have to overload the
tos with the RTO_ONLINK flag, like RT_CONN_FLAGS() does.
For callers that don't pass a struct sock, this doesn't change anything
as the scope is still set to RT_SCOPE_UNIVERSE when sk is NULL.
Callers that passed a struct sock and used RT_CONN_FLAGS(sk) or
RT_CONN_FLAGS_TOS(sk, tos) for the tos are modified to use
ip_sock_tos(sk) and RT_TOS(tos) respectively, as overloading tos with
the RTO_ONLINK flag now becomes unnecessary.
In drivers/net/amt.c, all ip_route_output_ports() calls use a 0 tos
parameter, ignoring the SOCK_LOCALROUTE flag of the socket. But the sk
parameter is a kernel socket, which doesn't have any configuration path
for setting SOCK_LOCALROUTE anyway. Therefore, ip_route_output_ports()
will continue to initialise scope with RT_SCOPE_UNIVERSE and amt.c
doesn't need to be modified.
Also, remove RT_CONN_FLAGS() and RT_CONN_FLAGS_TOS() from route.h as
these macros are now unused.
The objective is to eventually remove RTO_ONLINK entirely to allow
converting ->flowi4_tos to dscp_t. This will ensure proper isolation
between the DSCP and ECN bits, thus minimising the risk of introducing
bugs where TOS values interfere with ECN.
Wojciech Drewek [Mon, 5 Feb 2024 13:03:57 +0000 (14:03 +0100)]
ice: Fix debugfs with devlink reload
During devlink reload it is needed to remove debugfs entries
correlated with only one PF. ice_debugfs_exit() removes all
entries created by ice driver so we can't use it.
Introduce ice_debugfs_pf_deinit() in order to release PF's
debugfs entries. Move ice_debugfs_exit() call to ice_module_exit(),
it makes more sense since ice_debugfs_init() is called in
ice_module_init() and not in ice_probe().
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Reviewed-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Wojciech Drewek [Mon, 5 Feb 2024 13:03:56 +0000 (14:03 +0100)]
ice: Remove and readd netdev during devlink reload
Recent changes to the devlink reload (commit 9b2348e2d6c9
("devlink: warn about existing entities during reload-reinit"))
force the drivers to destroy devlink ports during reinit.
Adjust ice driver to this requirement, unregister netdvice, destroy
devlink port. ice_init_eth() was removed and all the common code
between probe and reload was moved to ice_load().
During devlink reload we can't take devl_lock (it's already taken)
and in ice_probe() we have to lock it. Use devl_* variant of the API
which does not acquire and release devl_lock. Guard ice_load()
with devl_lock only in case of probe.
Suggested-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Grzegorz Nitka [Wed, 6 Dec 2023 19:29:19 +0000 (20:29 +0100)]
ice: add support for 3k signing DDP sections for E825C
E825C devices shall support the new signing type of RSA 3K for new DDP
section (SEGMENT_SIGN_TYPE_RSA3K_E825 (5) - already in the code).
The driver is responsible to verify the presence of correct signing type.
Add 3k signinig support for E825C devices based on mac_type:
ICE_MAC_GENERIC_3K_E825;
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Grzegorz Nitka [Wed, 6 Dec 2023 19:29:18 +0000 (20:29 +0100)]
ice: Add helper function ice_is_generic_mac
E800 series devices have a couple of quirks:
1. Sideband control queues are not supported
2. The registers that the driver needs to program for the "Precision
Time Protocol (PTP)" feature are different for E800 series devices
compared to other devices supported by this driver.
Both these require conditional logic based on the underlying device we
are dealing with.
The function ice_is_sbq_supported added by commit 8f5ee3c477a8
("ice: add support for sideband messages") addresses (1).
The same function can be used to address (2) as well
but this just looks weird readability wise in cases that have nothing
to do with sideband control queues:
if (ice_is_sbq_supported(hw))
/* program register A */
else
/* program register B */
For these cases, the function ice_is_generic_mac introduced by this
patch communicates the idea/intention better. Also rework
ice_is_sbq_supported to use this new function.
As side-band queue is supported for E825C devices, it's mac_type is
considered as generic mac_type.
Co-developed-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Grzegorz Nitka [Wed, 6 Dec 2023 19:29:17 +0000 (20:29 +0100)]
ice: introduce new E825C devices family
Introduce new Intel Ethernet E825C family devices.
Add new PCI device IDs which are going to be supported by the
driver:
- 579C: Intel(R) Ethernet Connection E825-C for backplane
- 579D: Intel(R) Ethernet Connection E825-C for QSFP
- 579E: Intel(R) Ethernet Connection E825-C for SFP
- 579F: Intel(R) Ethernet Connection E825-C for SGMII
Add helper function ice_is_e825c() to verify if the running device
belongs to E825C family.
Co-developed-by: Jan Glaza <jan.glaza@intel.com> Signed-off-by: Jan Glaza <jan.glaza@intel.com> Co-developed-by: Michal Michalik <michal.michalik@intel.com> Signed-off-by: Michal Michalik <michal.michalik@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Marc Kleine-Budde [Mon, 12 Feb 2024 16:16:08 +0000 (17:16 +0100)]
Merge patch series "can: m_can: Optimizations for m_can/tcan part 2"
Markus Schneider-Pargmann <msp@baylibre.com> says:
The series implements many small and bigger throughput improvements and
adds rx/tx coalescing at the end.
Changes in v7:
- Rebased to v6.8-rc1
- Fixed NULL pointer dereference in m_can_clean() on am62 that happened
when doing ip link up, ip link down, ip link up
- Fixed a racecondition on am62 observed with high throughput tests.
netdev_completed_queue() was called before netdev_sent_queue() as the
interrupt was processed so fast. netdev_sent_queue() is now reported
before the actual sent is done.
- Fixed an initializing issue on am62 where active interrupts are
getting lost between runs. Fixed by resetting cdev->active_interrupts
in m_can_disable_all_interrupts()
- Removed m_can_start_fast_xmit() because of a reordering of operations
due to above mentioned race condition
Changes in v6:
- Rebased to v6.6-rc2
- Added two small changes for the newly integrated polling feature
- Reuse the polling hrtimer for coalescing as the timer used for
coalescing has a similar purpose as the one for polling. Also polling
and coalescing will never be active at the same time.
Changes in v5:
- Add back parenthesis in m_can_set_coalesce(). This will make
checkpatch unhappy but gcc happy.
- Remove unused fifo_header variable in m_can_tx_handler().
- Rebased to v6.5-rc1
Changes in v4:
- Create and use struct m_can_fifo_element in m_can_tx_handler
- Fix memcpy_and_pad to copy the full buffer
- Fixed a few checkpatch warnings
- Change putidx to be unsigned
- Print hard_xmit error only once when TX FIFO is full
Changes in v3:
- Remove parenthesis in error messages
- Use memcpy_and_pad for buffer copy in 'can: m_can: Write transmit
header and data in one transaction'.
- Replace spin_lock with spin_lock_irqsave. I got a report of a
interrupt that was calling start_xmit just after the netqueue was
woken up before the locked region was exited. spin_lock_irqsave should
fix this. I attached the full stack at the end of the mail if someone
wants to know.
- Rebased to v6.3-rc1.
- Removed tcan4x5x patches from this series.
Changes in v2:
- Rebased on v6.2-rc5
- Fixed missing/broken accounting for non peripheral m_can devices.
m_can supports submitting multiple transmits with one register write.
This is an interesting option to reduce the number of SPI transfers for
peripheral chips.
The m_can_tx_op is extended with a bool that signals if it is the last
transmission and the submit should be executed immediately.
The worker then writes the skb to the FIFO and submits it only if the
submit bool is set. If it isn't set, the worker will write the next skb
which is waiting in the workqueue to the FIFO, etc.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:18 +0000 (10:32 +0100)]
can: m_can: Use tx_fifo_in_flight for netif_queue control
The network queue is currently always stopped in start_xmit and
continued in the interrupt handler. This is not possible anymore if we
want to keep multiple transmits in flight in parallel.
Use the previously introduced tx_fifo_in_flight counter to control the
network queue instead. This has the benefit of not needing to ask the
hardware about fifo status.
This patch stops the network queue in start_xmit if the number of
transmits in flight reaches the size of the fifo and wakes up the queue
from the interrupt handler once the transmits in flight drops below the
fifo size. This means any skbs over the limit will be rejected
immediately in start_xmit (it shouldn't be possible at all to reach that
state anyways).
The maximum number of transmits in flight is the size of the fifo.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:17 +0000 (10:32 +0100)]
can: m_can: Introduce a tx_fifo_in_flight counter
Keep track of the number of transmits in flight.
This patch prepares the driver to control the network interface queue
based on this counter. By itself this counter be
implemented with an atomic, but as we need to do other things in the
critical sections later I am using a spinlock instead.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:16 +0000 (10:32 +0100)]
can: m_can: Use the workqueue as queue
The current implementation uses the workqueue for peripheral chips to
submit work. Only a single work item is queued and used at any time.
To be able to keep more than one transmit in flight at a time, prepare
the workqueue to support multiple transmits at the same time.
Each work item now has a separate storage for a skb and a pointer to
cdev. This assures that each workitem can be processed individually.
The workqueue is replaced by an ordered workqueue which makes sure that
only a single worker processes the items queued on the workqueue. Also
items are ordered by the order they were enqueued. This removes most of
the concurrency the workqueue normally offers. It is not necessary for
this driver.
The cleanup functions have to be adopted a bit to handle this new
mechanism.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:15 +0000 (10:32 +0100)]
can: m_can: Cache tx putidx
m_can_tx_handler is the only place where data is written to the tx fifo.
We can calculate the putidx in the driver code here to avoid the
dependency on the txfqs register.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:13 +0000 (10:32 +0100)]
can: m_can: Add tx coalescing ethtool support
Add TX support to get/set functions for ethtool coalescing.
tx-frames-irq and tx-usecs-irq can only be set/unset together.
tx-frames-irq needs to be less than TXE and TXB.
As rx and tx share the same timer, rx-usecs-irq and tx-usecs-irq can be
enabled/disabled individually but they need to have the same value if
enabled.
Polling is excluded from TX irq coalescing.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/20240207093220.2681425-8-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:12 +0000 (10:32 +0100)]
can: m_can: Add rx coalescing ethtool support
Add the possibility to set coalescing parameters with ethtool.
rx-frames-irq and rx-usecs-irq can only be set and unset together as the
implemented mechanism would not work otherwise. rx-frames-irq can't be
greater than the RX FIFO size.
Also all values can only be changed if the chip is not active.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:11 +0000 (10:32 +0100)]
can: m_can: Implement transmit coalescing
Extend the coalescing implementation for transmits.
In normal mode the chip raises an interrupt for every finished transmit.
This implementation switches to coalescing mode as soon as an interrupt
handled a transmit. For coalescing the watermark level interrupt is used
to interrupt exactly after x frames were sent. It switches back into
normal mode once there was an interrupt with no finished transmit and
the timer being inactive.
The timer is shared with receive coalescing. The time for receive and
transmit coalescing timers have to be the same for that to work. The
benefit is to have only a single running timer.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:10 +0000 (10:32 +0100)]
can: m_can: Implement receive coalescing
m_can offers the possibility to set an interrupt on reaching a watermark
level in the receive FIFO. This can be used to implement coalescing.
Unfortunately there is no hardware timeout available to trigger an
interrupt if only a few messages were received within a given time. To
solve this I am using a hrtimer to wake up the irq thread after x
microseconds.
The timer is always started if receive coalescing is enabled and new
received frames were available during an interrupt. The timer is stopped
if during a interrupt handling no new data was available.
If the timer is started the new item interrupt is disabled and the
watermark interrupt takes over. If the timer is not started again, the
new item interrupt is enabled again, notifying the handler about every
new item received.
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:08 +0000 (10:32 +0100)]
can: m_can: Move hrtimer init to m_can_class_register
The hrtimer_init() is called in m_can_plat_probe() and the hrtimer
function is set in m_can_class_register(). For readability it is better
to keep these two together in m_can_class_register().
Markus Schneider-Pargmann [Wed, 7 Feb 2024 09:32:07 +0000 (10:32 +0100)]
can: m_can: Start/Cancel polling timer together with interrupts
Interrupts are enabled/disabled in more places than just m_can_start()
and m_can_stop(). Couple the polling timer with enabling/disabling of
all interrupts to achieve equivalent behavior.
Cc: Judith Mendez <jm@ti.com> Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrupt") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20240207093220.2681425-2-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc Kleine-Budde [Mon, 12 Feb 2024 15:58:55 +0000 (16:58 +0100)]
Merge patch series "can: esd: add support for esd GmbH PCIe/402 CAN interface"
Stefan Mätje <stefan.maetje@esd.eu> says:
The purpose of this patch is to introduce a new CAN driver to support
the esd GmbH 402 family of CAN interface boards. The hardware design
is based on a CAN controller implemented in a FPGA attached to a
PCIe link.
More information on these boards can be found following the links
included in the commit message.
This patch supports all boards but will operate the CAN-FD capable
boards only in Classic-CAN mode. The CAN-FD support will be added
when the initial patch has stabilized.
Changed in v11:
No functional, only editorial changes due to feedback on v10.
- Make lifetime of macros used for hardware timestamp calculation
very short by #undef-ing them after use.
- Fixed insertion order of new entry in MAINTAINERS file.
Changed in v10:
Most changes due to feedback by Vincent Mailhol
https://lore.kernel.org/linux-can/CAMZ6RqLOAC930GNOU+pWuoi6FgYwFOuFrSyAzVjvE2fuVgy8oA@mail.gmail.com
- Add support for ethtool operations by using default operations
provided by the can_dev module for drivers with hardware time
stamp support.
- Factor out core unregistration into pci402_unregister_core().
- Factor out getting next TX fifo index into acc_tx_fifo_next().
- Stop counting alloc_can_err_skb() failures in rx_dropped statistic.
- Add CAN_ERR_CNT flag in CAN error frames as needed.
- Rework function acc_reset_fpga(). To clear I^2C bus enable bit
is not necessary after FPGA reset.
- Simplify struct acc_bmmsg_rxtxdone layout.
- Additional non functional changes due to feedback by Vincent
- Some spelling corrections: ESDACC -> esdACC
Changes in v9:
- Fix returning success error code in case of allocation failure in
pci402_probe().
Changes in v8:
- Rebased to 6.6-rc2 on linux-can-next branch main
Changes in v7:
- Numerous changes. Find the quoted with inline comments about changes
below after the changes list. Stuff that I don't understand and
where I have questions is marked with ????.
Unfortunately I will be AFK till 28th of November.
Changes in v6:
- Fixed the statistic handling of RX overrun errors and increase
net_device_stats::rx_errors instead of net_device_stats::rx_dropped.
- Added a patch to not increase rx statistics when generating a CAN
rx error message frame as suggested on the linux-can list.
- Added a patch to not not increase rx_bytes statistics for RTR frames
as suggested on the linux-can list.
The last two patches change the statistics handling from the previous
style used in other drivers to the newly suggested one.
Changes in v5:
- Added the initialization for netdev::dev_port as it is implemented
for another CAN driver. See
https://lore.kernel.org/linux-can/20211026180553.1953189-1-mailhol.vincent@wanadoo.fr
Changes in v4:
- Fixed the build failure on ARCH=arm64 that was found by the Intel
kernel test robot. See
https://lore.kernel.org/linux-can/202109120608.7ZbQXkRh-lkp@intel.com
Removed error monitoring code that used GCC's built-in compiler
functions for atomic access (__sync_* functions). GCC versions
after 9 (tested with "gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04)")
don't implement the intrinsic atomic as in-line code but call
"__aarch64_ldadd4_acq_rel" on arm64. This GCC support function
is not exported by the kernel and therefore the module build
post-processing fails.
Removed that code because the error monitoring never showed a
problem during the development this year.
Changes in v3:
- Rework the bus-off restart logic in acc_set_mode() and
handle_core_msg_errstatechange() to call netif_wake_queue() from the
error active event.
- Changed pci402_init_card() to allocate a variable sized array of
struct acc_core using devm_kcalloc() instead of using a fixed size
array in struct pci402_card.
- Changed handle_core_msg_txabort() to release aborted TX frames in
TX FIFO order.
- Fixed the acc_close() function to abort all pending TX request in
esdACC controller.
- Fixed counting of transmit aborts in handle_core_msg_txabort().
It is now done like in can_flush_echo_skb().
- Fixed handle_core_msg_buserr() to create error frames including the
CAN RX and TX error counters that were missing.
- Fixed acc_set_bittiming() neither to touch LOM mode setting of
esdACC controller nor to enter or leave RESET mode.
The esdACC controller is going active on the CAN bus in acc_open()
and is going inactive (RESET mode) again in acc_close().
- Rely on the automatic release of memory fetched by devm_kzalloc().
But still use devm_irq_free() explicitely to make sure that the
interrupt handler is disconnected at that point.
This avoids a possible crash in non-MSI mode due to the IRQ
triggered by another device on the same PCI IRQ line.
- Changed to use DMA map API instead of pci_*_consistent compatibility
wrappers.
- Fixed stale email references and updated copyright information.
- Removed any traces of future CAN-FD support.
Changes in v2:
- Avoid warning triggered by -Wshift-count-overflow on architectures
with 32-bit dma_addr_t.
- Fixed Makefile not to build the kernel module always. Doing this
renamed esd402_pci.c to esd_402_pci-core.c as recommended by Marc.
Stefan Mätje [Wed, 22 Nov 2023 16:02:11 +0000 (17:02 +0100)]
can: esd: add support for esd GmbH PCIe/402 CAN interface family
This patch adds support for the PCI based PCIe/402 CAN interface family
from esd GmbH that is available with various form factors
(https://esd.eu/en/products/402-series-can-interfaces).
All boards utilize a FPGA based CAN controller solution developed
by esd (esdACC). For more information on the esdACC see
https://esd.eu/en/products/esdacc.
This driver detects all available CAN interface board variants of
the family but atm. operates the CAN-FD capable devices in
Classic-CAN mode only! A later patch will introduce the CAN-FD
functionality in this driver.
Co-developed-by: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://lore.kernel.org/all/20231122160211.2110448-3-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Oliver Hartkopp [Fri, 8 Dec 2023 16:57:29 +0000 (17:57 +0100)]
can: isotp: support dynamic flow control parameters
The ISO15765-2 standard supports to take the PDUs communication parameters
blocksize (BS) and Separation Time minimum (STmin) either from the first
received flow control (FC) "static" or from every received FC "dynamic".
Add a new CAN_ISOTP_DYN_FC_PARMS flag to support dynamic FC parameters.
Nicolas Maier [Sat, 20 Jan 2024 08:10:18 +0000 (09:10 +0100)]
can: bcm: add recvmsg flags for own, local and remote traffic
CAN RAW sockets allow userspace to tell if a received CAN frame comes
from the same socket, another socket on the same host, or another host.
See commit 1e55659ce6dd ("can-raw: add msg_flags to distinguish local
traffic"). However, this feature is missing in CAN BCM sockets.
Add the same feature to CAN BCM sockets. When reading a received frame
(opcode RX_CHANGED) using recvmsg, two flags in msg->msg_flags may be
set following the previous convention (from CAN RAW), to distinguish
between 'own', 'local' and 'remote' CAN traffic.
Eric Dumazet [Fri, 9 Feb 2024 15:31:01 +0000 (15:31 +0000)]
netfilter: conntrack: expedite rcu in nf_conntrack_cleanup_net_list
nf_conntrack_cleanup_net_list() is calling synchronize_net()
while RTNL is not held. This effectively calls synchronize_rcu().
synchronize_rcu() is much slower than synchronize_rcu_expedited(),
and cleanup_net() is currently single threaded. In many workloads
we want cleanup_net() to be faster, in order to free memory and various
sysfs and procfs entries as fast as possible.
Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 9 Feb 2024 15:31:00 +0000 (15:31 +0000)]
net: use synchronize_rcu_expedited in cleanup_net()
cleanup_net() is calling synchronize_rcu() right before
acquiring RTNL.
synchronize_rcu() is much slower than synchronize_rcu_expedited(),
and cleanup_net() is currently single threaded. In many workloads
we want cleanup_net() to be fast, in order to free memory and various
sysfs and procfs entries as fast as possible.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 9 Feb 2024 15:30:58 +0000 (15:30 +0000)]
bridge: vlan: use synchronize_net() when holding RTNL
br_vlan_flush() and nbp_vlan_flush() should use synchronize_net()
instead of syncronize_rcu() to release RTNL sooner.
Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 9 Feb 2024 15:30:56 +0000 (15:30 +0000)]
ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()
As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops
in igmp6_event_query() and igmp6_event_report()")) I think the
synchronize_net() call in ipv6_mc_down() is not needed.
Under load, synchronize_net() can last between 200 usec and 5 ms.
KASAN seems to agree as well.
Fixes: f185de28d9ae ("mld: add new workqueues for process mld events") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Taehee Yoo <ap420073@gmail.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Suraj Jaiswal [Fri, 9 Feb 2024 08:50:12 +0000 (14:20 +0530)]
net: stmmac: Add driver support for common safety IRQ
Add support to listen HW safety IRQ like ECC(error
correction code), DPP(data path parity), FSM(finite state
machine) fault in common IRQ line.
Signed-off-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Suraj Jaiswal [Fri, 9 Feb 2024 08:50:11 +0000 (14:20 +0530)]
dt-bindings: net: qcom,ethqos: add binding doc for safety IRQ for sa8775p
Add binding doc for safety IRQ. The safety IRQ will be
triggered for ECC(error correction code), DPP(data path
parity), FSM(finite state machine) error.
Signed-off-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Heiner Kallweit [Fri, 9 Feb 2024 06:47:39 +0000 (07:47 +0100)]
tg3: fix bug caused by uninitialized variable
The reported bug is caused by using mii_eee_cap1_mod_linkmode_t()
with an uninitialized bitmap. Fix this by zero-initializing the
struct containing the bitmap.
Fixes: 9bc791341bc9a5c22b ("tg3: convert EEE handling to use linkmode bitmaps") Reported-by: Srikanth Aithal <sraithal@amd.com> Tested-by: Srikanth Aithal <sraithal@amd.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 12 Feb 2024 10:42:17 +0000 (10:42 +0000)]
Merge branch 'dsa-realtek-common'
Luiz Angelo Daros de Luca says:
====================
net: dsa: realtek: variants to drivers, interfaces to a common module
The current driver consists of two interface modules (SMI and MDIO) and
two family/variant modules (RTL8365MB and RTL8366RB). The SMI and MDIO
modules serve as the platform and MDIO drivers, respectively, calling
functions from the variant modules. In this setup, one interface module
can be loaded independently of the other, but both variants must be
loaded (if not disabled at build time) for any type of interface. This
approach doesn't scale well, especially with the addition of more switch
variants (e.g., RTL8366B), leading to loaded but unused modules.
Additionally, this also seems upside down, as the specific driver code
normally depends on the more generic functions and not the other way
around.
Each variant module was converted into real drivers, serving as both a
platform driver (for switches connected using the SMI interface) and an
MDIO driver (for MDIO-connected switches). The relationship between the
variant and interface modules is reversed, with the variant module now
calling both interface functions (if not disabled at build time). While
in most devices only one interface is likely used, the interface code is
significantly smaller than a variant module, consuming fewer resources
than the previous code. With variant modules now functioning as real
drivers, compatible strings are published only in a single variant
module, preventing conflicts.
The patch series introduces a new common module for functions shared by
both variants. This module also absorbs the two previous interface
modules, as they would always be loaded anyway.
The series relocates the user MII driver from realtek-smi to rtl83xx. It
is now used by MDIO-connected switches instead of the generic DSA
driver. There's a change in how this driver locates the MDIO node. It
now only searches for a child node named "mdio".
The dsa_switch in realtek_priv->ds is now embedded in the struct. It is
always in use and avoids dynamic memory allocation.
Testing has been performed with an RTL8367S (rtl8365mb) using MDIO
interface and an RTL8366RB (rtl8366) with SMI interface.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Fri, 9 Feb 2024 05:03:47 +0000 (02:03 -0300)]
net: dsa: realtek: embed dsa_switch into realtek_priv
Embed dsa_switch within realtek_priv to eliminate the need for a second
memory allocation.
Suggested-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Fri, 9 Feb 2024 05:03:45 +0000 (02:03 -0300)]
net: dsa: realtek: migrate user_mii_bus setup to realtek_dsa
In the user MDIO driver, despite numerous references to SMI, including
its compatible string, there's nothing inherently specific about the SMI
interface in the user MDIO bus. Consequently, the code has been migrated
to the rtl83xx module. All references to SMI have been eliminated.
The MDIO bus id was changed from Realtek-<switch id> to the switch
devname suffixed with :user_mii, giving more information about the bus
it is referencing.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Fri, 9 Feb 2024 05:03:44 +0000 (02:03 -0300)]
net: dsa: realtek: clean user_mii_bus setup
Remove the line assigning dev.of_node in mdio_bus as subsequent
of_mdiobus_register will always overwrite it.
As discussed in [1], allow the DSA core to be simplified, by not
assigning ds->user_mii_bus when the MDIO bus is described in OF, as it
is unnecessary.
Since commit 3b73a7b8ec38 ("net: mdio_bus: add refcounting for fwnodes
to mdiobus"), we can put the "mdio" node just after the MDIO bus
registration.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Fri, 9 Feb 2024 05:03:43 +0000 (02:03 -0300)]
net: dsa: realtek: get internal MDIO node by name
The binding docs requires for SMI-connected devices that the switch
must have a child node named "mdio" and with a compatible string of
"realtek,smi-mdio". Meanwile, for MDIO-connected switches, the binding
docs only requires a child node named "mdio".
This patch changes the driver to use the common denominator for both
interfaces, looking for the MDIO node by name, ignoring the compatible
string.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Fri, 9 Feb 2024 05:03:42 +0000 (02:03 -0300)]
net: dsa: realtek: merge rtl83xx and interface modules into realtek_dsa
Since rtl83xx and realtek-{smi,mdio} are always loaded together,
we can optimize resource usage by consolidating them into a single
module.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
The reset during probe was moved to the end of the common probe. This way,
we avoid a reset if anything else fails.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / users / hch / block.git / log