Dave Penkler [Wed, 18 Sep 2024 12:18:51 +0000 (14:18 +0200)]
staging: gpib: Add user api include files
User api include files used by drivers and userland code.
The files are also distributed with the userland package.
Since these include files have been used by many applications we
had to keep the camelCase enums, typedefs and uint8_t declarations.
Wei Wang from Realsil contributed this driver in 2011.
The following reasons lead to the removal:
- This driver generates maintenance workload
- Did not find minimal documentation on the web.
- No blog entries about anyone using the rts5208 and rts5288 during the
last years.
- Did not find any device that may has it in and is still available on
the market.
vchiq_pagelist.h only defines one struct and a couple of macros.
It can be merged with vchiq_core since all the pagelist related
function helpers are now in vchiq_core for bulk transfers.
Move the struct and related macros to vchiq_core header and drop
vchiq_pagelist.h.
staging: vchiq_core: Move bulk data functions in vchiq_core
Bulk transfers core logic lives in vchiq_core.c, hence move all
the preparatory bulk data allocation helpers to vchiq_core.c (from
vchiq_arm).
The discrepancy was noticed when vchiq_prepare_bulk_data() and
vchiq_complete_bulk() are being used vchiq_core.c but are defined
in vchiq_arm. Now that they are now confined to vchiq_core.c,
they can be made static and their signatures from vchiq_core header
can be dropped.
vchiq_prepare_bulk_data() and vchiq_complete_bulk() depends on
struct vchiq_pagelist_info, cleanup_pagelist(), free_pagelist() and
create_pagelist() hence they are pulled in from vchiq_arm as well,
as part of this commit.
The function remote_event_signal() is declared in vchiq_core.h while
defined in vchiq_arm.c and used only in vchiq_core.c. Move the
definition to vchiq_core.c as it is only used in this file.
Also convert it to static and drop the function signature from
vchiq_core.h header. BELL2 doorbell macro is also moved from vchiq_arm
to vchiq_core as part of this change.
-EINTR is returned by vchiq_queue_message() on receiving a fatal
signal to the process. Since the process is deemed to be terminated
anyway, do not retry queuing with vchiq_queue_message() on -EINTR.
staging: vchiq_arm: Do not retry bulk transfers on -EINTR
-EINTR is returned by various vchiq bulk transfer code paths
on receiving a fatal signal to the process. Since the process is
deemed to be terminated anyway, do not retry the bulk transfer
on -EINTR.
staging: vchiq_core: Return -EINTR when bulk transfers are interrupted
Bulk transfers for various VCHIQ modes use mutex_lock_killable() and
wait_for_completion_killable() variations. Currently, -EAGAIN is
returned if these are interrupted by a fatal signal.
-EAGAIN may mislead the caller into thinking the operation can be
retried, while in reality, the process has received a fatal signal
and is terminating. Therefore, we should update the return value to
align with what these killable functions would return, specifically
-EINTR (Interrupted system call).
staging: vchiq_core: Return -EINTR in queue_message() on interrupt
queue_message() uses mutex_lock_killable() and
wait_for_completion_killable() variations of locking and wait event
completions respectively. These functions return either 0 (on success)
or -EINTR, if interrupted by a fatal signal (as documented in the
kernel).
However, queue_message() is currently returning -EAGAIN if these
killable functions are interrupted by fatal signals. Bubbling up
-EAGAIN might give a sense to the caller, that the code path can
be re-tried however, in actual sense, a fatal signal has been
received by the process and the process is going away.
Hence, we should align the return value with what these killable
versions will return i.e. -EINTR (Interrupted system call).
staging: vchiq_core: Return on all errors from queue_message()
In vchiq_connect_internal(), a MAKE_CONNECT message is queued
if the connection is disconnected, but only -EAGAIN error is
checked on the error path and returned.
However, queue_message() can fail with other errors as well hence,
vchiq_connect_internal() should return in those cases as well.
staging: vchiq_core: Use killable wait completions for bulk transfers
commit f27e47bc6b8b ("staging: vchiq: use completions instead of
semaphores") introduced completions for events in vchiq interface.
It introduced _interruptible() version of completions for waiting
on events. However, it missed a subtle down_interruptible() macro
override in vchiq_killable.h, which used to mask most of the signals
and only interrupt on fatal ones.
The above issue was fixed in commit a772f116702e ("staging: vchiq: switch
to wait_for_completion_killable"). Given the override logic of
down_interruptible() that existed in vchiq_killable.h, that commit
fixed the completions with the correct variation i.e. killable() family
of functions.
However, commit a772f116702e ("staging: vchiq: switch to
wait_for_completion_killable") later got reverted [1] due to high CPU
load noticed by various downstream and upstream distributions [2].
Reverting the commit solved this problem but the root cause was never
diagonsed and the entire commit was reverted.
This patch brings back killable version of wait events but only for
bulk transfers and queue_message() transfer code paths.
The idea is to bring back killable versions for various event
completions in a phased manner so that we do not re-regress again as
noticed in [2]. Hence, no other wait events are converted from
interruptible -> killable in this patch.
Since the bulk transfers are no longer interruptible (but killable),
drop the "_interruptible" suffix from all vchiq_bulk_xfer_* functions.
staging: Switch back to struct platform_driver::remove()
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all staging drivers to use .remove(), with the eventual goal to
drop struct platform_driver::remove_new(). As .remove() and .remove_new()
have the same prototypes, conversion is done by just changing the structure
member name in the driver initializer.
staging: olpc_dcon: Drop explicit initialization of struct i2c_device_id::driver_data to 0
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
staging: most: i2c: Drop explicit initialization of struct i2c_device_id::driver_data to 0
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While touching the initializer, also remove the comma after the sentinel
entry.
Commit ed394dbf5371b03a5335a7ba1973ba124c0ced3d replaced Forest Bond
with Philipp Hortmann as vt665X maintainer in MAINTAINERS, but
drivers/staging/vt6656/TODO was not changed, rendering it stale. This
patch fixes it.
This merges up to commit a0efa2f362a6 ("Merge net-next/main to resolve
conflicts") from wireless-next into the staging-next branch to handle
the removal of a staging driver easier (it happened in the wireless-next
branch). That way we don't have developers confused and start
submitting changes for this driver that is now deleted.
Johannes Berg [Wed, 9 Oct 2024 06:59:14 +0000 (08:59 +0200)]
Merge net-next/main to resolve conflicts
The wireless-next tree was based on something older, and there
are now conflicts between -rc2 and work here. Merge net-next,
which has enough of -rc2 for the conflicts to happen, resolving
them in the process.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tarun Alle [Mon, 7 Oct 2024 06:39:43 +0000 (12:09 +0530)]
net: phy: microchip_t1: SQI support for LAN887x
Add support for measuring Signal Quality Index for LAN887x T1 PHY.
Signal Quality Index (SQI) is measure of Link Channel Quality from
0 to 7, with 7 as the best. By default, a link loss event shall
indicate an SQI of 0.
====================
net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110
This series enables auto negotiation for the mv88q2110 device.
Previously this feature have been disabled for mv88q2110, while enabled
for other devices supported by this driver.
The initial driver implementation states this is due to the
configuration sequence provided by the vendor did not work. By comparing
the initialization sequence of other devices this driver supports and
the out-of-tree PHY driver for mv88q2110 found in the Renesas BSP [1]
I was able to figure out a working configuration.
As I have no access to the datasheets of either of these devices it
would be super if someone who has could sanity check the initialization
sequence.
With this series I'm able to auto negotiate both 1000Mbps and 100Mbps
links without issue.
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 100baseT1/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT1/Full
1000baseT1/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT1/Full
1000baseT1/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred master
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Link detected: yes
SQI: 15/15
And the performance is good too. Without this change I was not able to
manually configure a 1000Mbps link, only 100Mbps ones. So this gives a
huge performance boost for my use-case.
Patch 1/3 and 2/3 are preparation patches that align and move functions
around as the mv88q2110 code paths can now reuses much of what is done
for mv88q2220. While patch 3/3 adds the new initialization sequence and
removes the auto negotiation limit for mv88q2110.
net: phy: marvell-88q2xxx: Enable auto negotiation for mv88q2110
The initial marvell-88q2xxx driver only supported the Marvell 88Q2110
PHY without auto negotiation support. The reason documented states that
the provided initialization sequence did not to work. Now a method to
enable auto negotiation have been found by comparing the initialization
of other supported devices and an out-of-tree PHY driver.
Perform the minimal needed initialization of the PHY to get auto
negotiation working and remove the limitation that disables the auto
negotiation feature for the mv88q2110 device.
With this change a 1000Mbps full duplex link is able to be negotiated
between two mv88q2110 and the link works perfectly. The other side also
reflects the manually configure settings of the master device.
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 100baseT1/Full
1000baseT1/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT1/Full
1000baseT1/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT1/Full
1000baseT1/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred master
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Link detected: yes
SQI: 15/15
Before this change I was not able to manually configure 1000Mbps link,
only a 100Mpps link so this change providers an improvement in
performance for this device.
net: phy: marvell-88q2xxx: Make register writer function generic
In preparation to adding auto negotiation support to mv88q2110 move and
rename the helper function used to write an array of register values to
the PHY.
Just as for mv88q2220 devices this helper will be needed to for the
initial configuration of the mv88q2110 to support auto negotiation.
The function is moved verbatim, there is no change in behavior.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Stefan Eichenberger <eichest@gmail.com> Link: https://patch.msgid.link/20241005112412.544360-3-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: marvell-88q2xxx: Align soft reset for mv88q2110 and mv88q2220
The soft reset implementations for mv88q2110 and mv88q2220 differ as the
later need to consider that auto negation is supported on mv88q2220
devices. In preparation of enabling auto negotiation on mv88q2110 merge
the two rest functions into a device generic one.
The mv88q2220 behavior is kept as is but extended to wait for the reset
bit to be clears before continuing, as was done previously on mv88q2220.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Stefan Eichenberger <eichest@gmail.com> Link: https://patch.msgid.link/20241005112412.544360-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andrew Kreimer [Sun, 6 Oct 2024 13:08:29 +0000 (16:08 +0300)]
fsl/fman: Fix a typo
Fix a typo in comments: bellow -> below.
Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241006130829.13967-1-algonell@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Daniel Golle [Fri, 4 Oct 2024 16:18:16 +0000 (17:18 +0100)]
net: phy: aquantia: allow forcing order of MDI pairs
Despite supporting Auto MDI-X, it looks like Aquantia only supports
swapping pair (1,2) with pair (3,6) like it used to be for MDI-X on
100MBit/s networks.
When all 4 pairs are in use (for 1000MBit/s or faster) the link does not
come up with pair order is not configured correctly, either using
MDI_CFG pin or using the "PMA Receive Reserved Vendor Provisioning 1"
register.
Normally, the order of MDI pairs being either ABCD or DCBA is configured
by pulling the MDI_CFG pin.
However, some hardware designs require overriding the value configured
by that bootstrap pin. The PHY allows doing that by setting a bit in
"PMA Receive Reserved Vendor Provisioning 1" register which allows
ignoring the state of the MDI_CFG pin and another bit configuring
whether the order of MDI pairs should be normal (ABCD) or reverse
(DCBA). Pair polarity is not affected and remains identical in both
settings.
Introduce property "marvell,mdi-cfg-order" which allows forcing either
normal or reverse order of the MDI pairs from DT.
If the property isn't present, the behavior is unchanged and MDI pair
order configuration is untouched (ie. either the result of MDI_CFG pin
pull-up/pull-down, or pair order override already configured by the
bootloader before Linux is started).
Forcing normal pair order is required on the Adtran SDG-8733A Wi-Fi 7
residential gateway.
Daniel Golle [Fri, 4 Oct 2024 16:18:05 +0000 (17:18 +0100)]
dt-bindings: net: marvell,aquantia: add property to override MDI_CFG
Usually the MDI pair order reversal configuration is defined by
bootstrap pin MDI_CFG. Some designs, however, require overriding the MDI
pair order and force either normal or reverse order.
Add property 'marvell,mdi-cfg-order' to allow forcing either normal or
reverse order of the MDI pairs.
Petr Machata [Mon, 7 Oct 2024 16:26:09 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Lower TBF rate
The RED test uses a pair of TBF shapers. The first to get predictably-sized
stream of traffic, and second to get a 100% saturated chokepoint. To this
chokepoint it injects individual packets. Because the chokepoint is
saturated, these additional packets go straight to the backlog. This allows
the test to check RED behavior across various queue sizes.
The shapers are rated at 1Gbps, for historical reasons (before mlxsw
supported TBF offload, the test used port speed to create the chokepoints).
Machines with a low-power CPU may have trouble consistently generating
1Gbps of traffic, and the test then spuriously fails.
Instead, drop the rate to 200Mbps (Spectrum has a guaranteed shaper rate
granularity of 200Mbps, so anything lower is not guaranteed to work well).
Because that means fewer packets will be mirrored in the ECN-mark test,
adjust the passing condition accordingly.
Petr Machata [Mon, 7 Oct 2024 16:26:08 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Send more packets for drop tests
This test works by injecting into a port with a maxed-out queue a couple
packets and checks if a corresponding number of packets were dropped. This
has worked well on Spectrum<4, but on Spectrum-4 it has been noisy. This
is in line with the observation that on Spectrum-4, queue size tends to
fluctuate more. A handful of packets could then still be accepted to the
queue even though it was nominally full just recently.
In order to accommodate this behavior, send many more packets. The buffer
can fit N extra packets, but not N% packets. This therefore allows us to
set wider absolute margins, while actually narrowing them relatively.
Petr Machata [Mon, 7 Oct 2024 16:26:07 +0000 (18:26 +0200)]
selftests: mlxsw: sch_red_core: Sleep before querying queue depth
The qdisc stats are taken from the port's periodic HW stats, which are
updated once a second. We try to accommodate the latency by using busywait
in build_backlog().
The issue in that seems to be that when do_mark_test() builds the backlog,
it makes the decision whether to send more packets based on the first
instance of the queue depth stat exceeding the current value, when in fact
more traffic is on the way and the queue depth would increase further. This
leads to failures in TC 1 of mark-mirror test, where we see the following
failure:
Backlog fluctuates on Spectrum-4 much more than on <4. In practice we can
sample queue depth values going from about -12% to about +7% of the
configured RED limit. The test which checks the queue size has a limit of
+-10%, and as a result often fails. We attempted to fix the issue by
busywaiting for several seconds hoping to get within the bounds, but that
still proved to be too noisy (or the wait time would be impractically
long). Unfortunately we have to bump the value tolerance from 10% to 15%,
which in this patch do.
Backlog fluctuates on Spectrum-4 much more than on <4. Increasing the
desired backlog seems to help, as the constant fluctuations do not overlap
into the territory where packets are marked.
Jason Xing [Sat, 5 Oct 2024 22:26:09 +0000 (07:26 +0900)]
net-timestamp: namespacify the sysctl_tstamp_allow_data
Let it be tuned in per netns by admins.
Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20241005222609.94980-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There's no need for "future" extensions in an internal
struct, and we don't need a u32 for flags, use just a
u8. Also remove the unused IW_DESCR_FLAG_WAIT flag.
Johannes Berg [Mon, 7 Oct 2024 19:35:25 +0000 (21:35 +0200)]
wifi: remove iw_public_data from struct net_device
Given the previous patches, we no longer need the
struct iw_public_data etc., it's only used by the
old Intel drivers (and ps3_gelic creates it but
then doesn't use it). Remove all of that, including
the pointer in struct net_device.
Johannes Berg [Mon, 7 Oct 2024 18:26:56 +0000 (20:26 +0200)]
staging: don't recommend using lib80211
No longer document drivers should switch to lib80211,
they really should never have done that. While at it,
also remove the recommendation to use cfg80211, if it
switches to mac80211 then it implicitly uses cfg80211
but doesn't need to do anything about that, normally.
Johannes Berg [Mon, 7 Oct 2024 18:26:55 +0000 (20:26 +0200)]
wifi: ipw2x00/lib80211: move remaining lib80211 into libipw
There's already much code in libipw that used to be shared
with more drivers, but now with the prior cleanups, those old
Intel ipw2x00 drivers are also the only ones using whatever is
now left of lib80211. Move lib80211 entirely into libipw.
projects / thirdparty / kernel / linux.git / log
